Mac stuff. Short summary: yes, it looks less centralized and probably would frustrate control-POV people; and yes, far fewer of the negatives of a single point of organization that makes your apps die if your OS goes down the tubes.
Some details, using Adobe Photoshop 7.0 as an example —
• Photoshop, like most OS X apps, is a “bundle” app. (Not all OS X apps are: Microsoft Excel, for instance, is an APPL file containing resources in its resource fork and other files in folders parallel to the Excel application file) With bundle apps, what appears in the OS X Finder to be a single file (and can be moved or deleted as a single file) is actually a folder, within which are the Mac equivalents of .dll files — in fact, some of them are even called filename.dll just like on a PC; a “Resouce” folder containing various icons and language-specific files that determine what shows onscreen depending on what language you’re using, etc; a PkgInfo file that contains the creator string (8BIM) and the type string (APPL, i.e., it’s an application); an internal .plist file called Info.plist — .plist files are XML files, some of which are within the application bundle like this and some of which are in the User’s Library/Preferences folder. This one for Photoshop contains version numbers and copyright strings, the “Get Info” string, etc; and a Classic folder containing the version of the program that will run under MacOS 9, along with the OS 9 version of the libary files, etc.; the User Registration file; … somewhere amidst these files is a file that informs the OS that Photoshop is one possible app that can open (let’s say) a TIFF file or a BMP file, so that when the user right-clicks such a file and goes to “Open With”, Photoshop appears in the list of possible apps, whereas it would not appear in the list if you right-clicked a FileMaker database file because it doesn’t do those. Since this info is embedded in Photoshop’s bundle, no reinstallation is necessary. In a non-bundle app such as Excel, similar info would be embedded in the Excel APPL file in one of the resources of its resource fork. The latter is the default method for older Mac systems (MacOS 9 and earlier). Under MacOS 9 and before, a disk-wide inventory of this information was kept, called the Desktop, and it would require rebuilding on occasion, e.g., your document icons could one day show up with “unknown document type” icons and the OS would say it did not know what to open it with when you double-clicked it; you’d rebuild the Desktop and the problem would go away. I’m not entirely sure how OS X polls, but it seems to me more dynamic, like an always in-process background task. Sometimes if I doubleclick a document icon immediately after boot, and the default application is on an external hard disk, the document will open with the wrong app or I’ll get the “no app associated with this file type” msg; after another second or two the OS finishes “polling” and the problem goes away on its own.
•From a control POV it would be harder to keep an app out of the hands of users. Hook up an external drive with the app on it, double-click, and you’re up and running due to no installation being required. (See bottom of post for brief discussion of exceptions).
• in the /Users/<yourname>/Library/Preferences folder, there’s a file, Adobe Photoshop 7.0 Paths, and a folder, Adobe Photoshop 7 Prefs, containing .psp files that save your most recent choices for various options within Photoshop, plus a folder containing your “Workspaces” (i.e., how you want all the palettes arranged on the 3 monitors you hook your laptop to at work as opposed to the single-monitor display arrangement you prefer when you’re working while commuting home on the bus). Photoshop doesn’t need these to run.
• also in /Users/<yourname>/Library/Preferences, a .plist file, com.adobe.Photoshop.plist, which stores the path to the most recent file you opened, and the most recent save-path to a file you saved. Photoshop doesn’t need these to run either.
• also in /Users/<yourname>/Library/Preferences, another .plist file, com.apple.Launchservices.plist, which stores my prefs about what to launch a file with extension .psd (Photoshop’s native extension) with Creator Code 8BLM (Photoshop’s creator code). In my case, surprisingly enough, the application of choice is GraphicConverter, because it will launch very quicklly and display the file for viewing; if I want to actually open a Photoshop file in Photoshop, I’d right-click the file and ask that it be opened in Photoshop. If this file were missing, neither the OS nor Photoshop would need it in order for Photoshop to function and open files; but if, let’s say, I had at some point told the OS that by default Photoshop should open all .jpg files of Creator Code JVWR (JPEGView), and then this file was overwritten, the OS would not launch Photoshop when I doubleclicked the .jpg file.
• For a given document file, unless the user has stored a different preference in that beforementioned com.apple.Launchservices.plist, there’s a hierarchy that determines what app launches when you doubleclick the file. a) If the document has a valid Creator Code, and the OS finds an app that owns that code, that’s the application that gets launched. The app doesn’t have to be “installed” and can be moved around at will or renamed because of how the polling works (i.e., it isn’t dependent on stored paths). b) If the document has no Creator Code or has a code for an app that’s not on the machine, but the document has a File Type code (e.g., “TIFF” or “XLS8”), the OS will fling it at the app designated as the default app for files of that file type (and if none is designated it will make an arbitrary assignment). c) If the document has no file type, but has a filename extension (e.g., “.fp5” or “.pdf”) the OS will hand it over to the default handler for untyped files of that file extension. If you reinstall the OS and have your applications remaining from a previous install (and/or reformat the hard drive but have some apps on another disk, etc), the OS may no longer know that application as the default handler for this or that file extension or file type Code, but will most likely honor it as the owner of files of its native Creator Code. Irritating exceptions are the Apple applications Preview, iTunes, and TextEdit, which will take over PDF and TIFF and JPEG, .MP3, and text files like a Mafia gangster with an expansion opportunity.
Exceptions in general: Some apps by their very nature need to be able to do things that could potentially violate security limitations imposed on user accounts. An example is Timbuktu, the remote-desktop program. On installation, such an app (after you’ve authorized it to do so) writes loading instructions to the root-level user equivalent of your user’s Library/Preferences file, and on subsequent launches the OS starts relevant services. In the case of Timbuktu, if you reinstall the OS and attempt to launch Timbuktu, you’ll have to reauthorize before the service that allows other computers to connect to yours will be started, and that service will no longer automatically launch on boot as it did before. Apps of this nature generally use the Installer and are usually distributed as “.pkg” files and require a password to make modifications requiring superuser (root) privileges. Many of them, unlike Timbuktu, will flat-out fail to work until you reinstall them; some will effectively reinstall themselves after authentication the first time you go to use them after an OS reinstall; a few, such as Timbuktu (again), do not reinstall any of the superuser-level modifications and will work normally but in “manual mode” where you have to launch and authenticate each time you boot in order to start up the service.