4 ms·

Can someone explain why a monolithic Registry is a good idea, compared to something like macOS's .plists? I can usually intuitively infer where the plist for a

Can someone explain why a monolithic Registry is a good idea, compared to something like macOS's .plists? I can usually intuitively infer where the plist for a particular app or subsystem may be stored, or just search for it using regular file system tools, and I can use many tools to read, edit and selectively backup/restore plists as well as compress them (something I make use of often, to restore settings only for specific apps on a fresh machine/installation, something that was very cumbersome to do with the Registry.) I also have yet to experience plist corruptions even once for even one file on macOS, but several times with the Registry during my time on Windows, with multiple unrelated parts of the monolith crumbling at the same time.

krackers 7y ago
Storing configuration as plaintext files is definitely a big positive, as it allows you to use standard and battle-tested file apis to manipulate them instead of an opaque blob that then requires an additional platform specific API. The only benefit I can see of a monolithic registry is that it's technically all organized in one central place, compared to say the Linux practice of scattering app settings in home directories (although XDG does help standardize this). But in practice the Windows approach seem to provide an unnecessarily tight coupling.
- CameronNemo 7y ago
  plists are XML, not plain text. Structured data need not be binary. Also on Linux you have dconf, which is literally a centralized, binary configuration storage backend. I believe it is being replaced with a more decentralized mechanism to ease container use cases.
grzm 7y ago
> "Can someone explain why a monolithic Registry is a good idea, compared to something like macOS's .plists?" https://en.wikipedia.org/wiki/Windows_Registry#Rationale https://en.wikipedia.org/wiki/Windows_Registry#Rationale The Registry has been around since Windows 3.1. While it's not required to use the Registry, I can imagine there's a large installed base of applications that do use it, and migrating off of something like this can take concerted effort if they decide it's worth the effort. When there's something I initially find incredulous, I try to take step back and recognize that very likely the people involved in making those decisions have a better perspective on the situation than I do. I've found Chesterton's Fence to be a useful metaphor. https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence Taking that into account, even my explanation is likely wrong. And even given everything you've said is true, there are any number of additional issues known to those involved than the ones you've put forth.
- Razengan 7y ago
  Windows used to have lots of .INI files, but almost all apps kept them all in C:\Windows or System or some such place. If only they had discovered the concept of subfolders, instead of shuttling them off into another monolithic container. I suspect having many subdirectories degraded filesystem performance at the time.
  - SmellyGeekBoy 7y ago
    Or just stick them all in a global store specifically for config files, say somewhere like /etc? This problem has been solved since the 1960s.
- makomk 7y ago
  The Windows 3.1 version really was just a registry though - it recorded COM object registrations and nothing else. The idea of dumping a whole bunch of unrelated system and app configuration in there was a Windows 95 thing. As for why they did it, that probably seemed like a good idea at the time and there's no way to get rid of it now even if we wanted to.
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 ago
  That 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 ago
    Some 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.
zvrba 7y ago
> Can someone explain why a monolithic Registry is a good idea, compared to something like macOS's .plists? Why monolithic may be good: because it's global and baked into the system. An application doesn't have to search for its config files. Registry is always there. It's a database. And it's better than INI or XML files because updates are transactional, and you can even have transactional updates over multiple keys. It also supports fine-grained access control. Manually implementing transactional updates in text files is a hassle and you can forget per-value ACLs... unless all of this is hidden behind a registry-like API.
- Razengan 7y ago
  What does being "global" mean here, and why is it good? macOS apps don't have to search for their config files either; support for them is baked into their system APIs as well. The macOS/iOS UserDefaults system is actually very nice, allowing multiple tiers/domains for precedence of settings. For example a specific setting may be optionally overridden for a single session via any app's launch arguments [0]. How do you achieve something like that with the Registry? The Registry architecture may make things easier for Microsoft, but the plist architecture seems to make things easier for users and developers. [0] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/UserDefaults/AboutPreferenceDomains/AboutPreferenceDomains.html#//apple_ref/doc/uid/10000059i-CH2-96930 https://developer.apple.com/library/archive/documentation/Co...

krackers 7y ago

Storing configuration as plaintext files is definitely a big positive, as it allows you to use standard and battle-tested file apis to manipulate them instead of an opaque blob that then requires an additional platform specific API. The only benefit I can see of a monolithic registry is that it's technically all organized in one central place, compared to say the Linux practice of scattering app settings in home directories (although XDG does help standardize this). But in practice the Windows approach seem to provide an unnecessarily tight coupling.

CameronNemo 7y ago
plists are XML, not plain text. Structured data need not be binary. Also on Linux you have dconf, which is literally a centralized, binary configuration storage backend. I believe it is being replaced with a more decentralized mechanism to ease container use cases.

grzm 7y ago

> "Can someone explain why a monolithic Registry is a good idea, compared to something like macOS's .plists?" https://en.wikipedia.org/wiki/Windows_Registry#Rationale https://en.wikipedia.org/wiki/Windows_Registry#Rationale The Registry has been around since Windows 3.1. While it's not required to use the Registry, I can imagine there's a large installed base of applications that do use it, and migrating off of something like this can take concerted effort if they decide it's worth the effort. When there's something I initially find incredulous, I try to take step back and recognize that very likely the people involved in making those decisions have a better perspective on the situation than I do. I've found Chesterton's Fence to be a useful metaphor. https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence Taking that into account, even my explanation is likely wrong. And even given everything you've said is true, there are any number of additional issues known to those involved than the ones you've put forth.

Razengan 7y ago
Windows used to have lots of .INI files, but almost all apps kept them all in C:\Windows or System or some such place. If only they had discovered the concept of subfolders, instead of shuttling them off into another monolithic container. I suspect having many subdirectories degraded filesystem performance at the time.
- SmellyGeekBoy 7y ago
  Or just stick them all in a global store specifically for config files, say somewhere like /etc? This problem has been solved since the 1960s.
makomk 7y ago
The Windows 3.1 version really was just a registry though - it recorded COM object registrations and nothing else. The idea of dumping a whole bunch of unrelated system and app configuration in there was a Windows 95 thing. As for why they did it, that probably seemed like a good idea at the time and there's no way to get rid of it now even if we wanted to.

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 ago
That 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 ago
  Some 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.

zvrba 7y ago

> Can someone explain why a monolithic Registry is a good idea, compared to something like macOS's .plists? Why monolithic may be good: because it's global and baked into the system. An application doesn't have to search for its config files. Registry is always there. It's a database. And it's better than INI or XML files because updates are transactional, and you can even have transactional updates over multiple keys. It also supports fine-grained access control. Manually implementing transactional updates in text files is a hassle and you can forget per-value ACLs... unless all of this is hidden behind a registry-like API.

Razengan 7y ago
What does being "global" mean here, and why is it good? macOS apps don't have to search for their config files either; support for them is baked into their system APIs as well. The macOS/iOS UserDefaults system is actually very nice, allowing multiple tiers/domains for precedence of settings. For example a specific setting may be optionally overridden for a single session via any app's launch arguments [0]. How do you achieve something like that with the Registry? The Registry architecture may make things easier for Microsoft, but the plist architecture seems to make things easier for users and developers. [0] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/UserDefaults/AboutPreferenceDomains/AboutPreferenceDomains.html#//apple_ref/doc/uid/10000059i-CH2-96930 https://developer.apple.com/library/archive/documentation/Co...