3 ms·
> Can someone explain why a monolithic Registry is a good idea, compared to something like macOS's .plists? Raymond Chen has a pretty good list: https://web.a
by cwyers 7y ago
> Can someone explain why a monolithic Registry is a good idea, compared to something like macOS's .plists?
Raymond Chen has a pretty good list:
https://web.archive.org/web/20071128134315/http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx https://web.archive.org/web/20071128134315/http://blogs.msdn...
- Razengan 7y agoThat link discusses the archaic .INI format versus Registry, not macOS .plist versus Registry, and already the very first point he states is outdated and irrelevant: > INI files don't support Unicode. His complaints about XML as an improvement over .INI don't make much sense either. The security of individual files and their folders can be more easily reasoned about using existing filesystem paradigms, than the nodes of some abstract tree inside the Registry. And you can use existing filesystem tools to monitor which apps are accessing which plists, meanwhile you have to rely on an entirely different set of tools custom-built just for interacting with the Registry. In practice, .plists feel much better as a user than the Registry does.
- asveikau 7y agoSome of the complaints in the article about INI also apply to plists. Can you atomically write a single property of a plist, in the presence of multiple concurrent readers and writers? Can you acl only some keys of a plist dictionary? Having keys and values as kernel objects solves those problems. Also worth noting that the registry is accessible from kernel mode drivers.