The registry is bloody amazing and a nice idea if I'm honest. It is far better than property lists or 6 million dotfiles crapped in your home directory as it's a lot more mobile. That's the one design decision I will say is a good one. I rather like it. It only breaks when people do silly things in it and that includes vendors.
It's a nice idea on paper, but it's responsible for HUGE issues in practice. It created a single point of failure so bad that MS had to virtualize the entire Registry to keep userspace apps from borking the OS entirely.
No, you don't want plists and dotfiles strewn everywhere, either. But that's not the only alternative to the registry.
Honestly, I haven't seen anyone come up with something as elegant as Apple-née-NeXT: the hierarchy of Library folders. It's strictly defined, it's easy to use for both developers (and advanced users; normal users never see them), and it's reasonably easy to fix things when they do go wrong. But being folders, it also affords flexibility to developers that the Registry does not. (For example, apps can use the Application Support subfolder to store a folder with support files, as opposed to having to have those support folders littering the Programs directory like on Windows.)
I will add that a related, though technically separate, issue is that many of the things stored in the Registry are things that shouldn't be defined statically at all. My go-to example of this is file associations. In Windows, there's a 1:1 association between a filetype (which itself is identified solely by file ending) and a single application (identified by its path) that "owns" that filetype, and that association is written by an installer or an application itself. Often, there is contention for a filetype, leading to a poor user experience.
In contrast, the Mac's Launch Services database is generated dynamically based on the applications currently available (meaning installed on the boot disk, or present on another disk or a network share). Applications include inside them a listing of its native/preferred file types, as well as of non-preferred file types it can open. Launch Services compiles these on the fly into an association for the default application, while maintaining a list of alternative applications to show in the Open With command. (For example, Photoshop will declare PSD as its native file type, but will also declare that it can open JPEG, TIFF, etc. Meanwhile, another photo editor might use PNG as its native file type, but will also declare that it can open PSD, JPEG, etc. By default, then, double-clicking a PSD file will open it in Photoshop, but right-clicking and choosing Open With will show you Photoshop at the top, and then your other photo editors, Preview, etc.)
The default application is selected based on some algorithm that considers the location, version, etc. You know how I said Launch Services is dynamic? It will literally update the database the instant another disk or network share is mounted. (Note that while the database is cached to disk for performance reasons across reboots, it's fundamentally dynamic, and the cache file can be deleted with no deleterious effects.)
(Everything it figures out algorithmically can be manually overridden, by the way. You can change the default application for a file type, or you can also set an individual file to open in a particular application when double-clicked, even if another application is the default for that file type. So you can have JPEGs open in Preview by default, but have specific JPEGs open in Photoshop, others in Affinity Photo, etc.)
Notably absent: the ability for an application to go in and overwrite another app's file associations. (Because the associations are a property of the applications, not of the operating system.)
(On the Mac, a file's filetype and "creator" application can be saved separately as extended attributes in the metadata, so that if the extension is lost, it can still be opened, while the "creator" tells the OS to open it with a particular application, as explained above.)
I disagree with Office. I maintain a very large document authoring and versioning system that plugs into word via VSTO (half mil LOC c#) and the whole shebang is a pile of shit that barely works. Look at Word.SaveAs vs Word.SaveAs2 vs Word.Save for example. The whole thing is a smelly poop. We have had to wrap every damn COM call in an exception wrapper to attempt to catch obscure things and react to them. Then there's the mess of trying to make that work across hundreds of different corporate proxy implementations because MSFT are smoking crack with WPAD etc.
I'm not a developer so I can't really respond to your specific issues, I just know what the developers at that company always told me: that everything else was much, much worse.
I'm not going to even mention Office 364.
Well, that's your own fault for choosing Office 365's l'il sibling who's short a chromosome!
That said (being that I haven't worked at that software company since 2012), what's wrong with Office 365? The only thing I'd heard was an issue for software devs was when they were using that App-V app streaming as Office Ready to Run (or whatever it was called), which didn't allow add-ons because the entire app runs in a virtualized environment that cannot see the local OS at all. But I think they stopped offering that, and now it's just regular local installs, just with subscription pricing instead of purchased licenses.
Home
Help
Search
Login
Register
