[OT] Windows registry (was: managing applications)

[Ben Scott]

On Jan 9, 2008 1:42 AM, Ric Werme <ewerme at comcast.net> wrote:
>>> Maybe we could keep everything in a binary database.  We'll call it a
>>> registry.....
>>
>>   DIE!  DIE!  DIE!  DIE!  DIE!  DI--   Er, sorry.  Reflex action.
>
> DIE is too strong a word.  Replace, simplify, constrain are far more
> useful.

  If someone else feels a need to reply to the above, please change
the subject line (like I just did), so we can tell the traffic apart.
The other thread is too useful to let it get dragged down by this.

  I considered just replying off-list, but I think this is a little
bit relevant to *nix, since I keep seeing various people/projects
trying to create a Windows-like registry on *nix.  Those who do not
understand MS-Windows are doomed to inflict it upon the rest of us.

  Anyhow:

  No, I don't think my response was too strong.

  The fact that Ric found a use for the registry that didn't
immediately break down doesn't mean it's a good idea.  The problems
with such massive, all-in-one, opaque systems are huge and many.  In
no particular order:

A1. Everything is shoved into what is presented as one giant database.
A2. Despite A1, it is actually stored in several files (called "hives").
A3. But the separation of A2 isn't in any useful way (you can't use
them separately, they don't divide useful functionality) so it just
complicates things further.
A4. If any single part of a registry hive is damaged, the entire
system becomes totally unusable.
A5. Binary.
A6. A5 means fixing any A4 is difficult to impossible.
A7. A5 means useful revision control is difficult to impossible.
A8. No way to add comments to entries.
A9. No way to selectively disable entries, or provide alternatives (in
text files, typically done with comments; see A8).
A10. A1 means it's very hard to find anything in particular.
A11. A1 and A7 means it's very hard to keep track of what software is
doing to the registry.
A12. A11 means trouble-shooting registry problems is near impossible.
A13. A8 means documentation is rare, and when it exists, must be
hunted down, and/or is often out-of-date.  (This isn't inherent, of
course, but A8 encourages it.)
A14. Because the hive files are always held open, you need special
methods to back them up.
A15. A1 and A5 means effectively merging/comparing registries is
difficult to impossible.
A16. Despite the heavy usage of linkages with GUIDs, class names, and
such, there's no actual constraints on validity or reference,  one of
the major reasons one usually uses to justify use a big, complicated
database.
A17. Performance is poor and size is limited (the other major reasons
one usually uses to justify use a big, complicated database)
A18. "Windows saved user ComputerName\UserName registry while an
application or service was still using the registry during log off.
The memory used by the user's registry has not been freed. The
registry will be unloaded when it is no longer in use. "
A19. Ever try to do something useful like do a mass update of a
setting in user registries?  No?  Try to keep it that way.  Death may
indeed be preferable.
A20. Despite the availability of fine-grain ACLs, security is a mess
in practice.  There's no locality of reference, so things have to be
managed at too low a level to be practical.
A21. Moving software between systems is an absolute horrid mess.
A22. Not compatible with portable apps.
A23. Concurrent write from multiple stations to a single user registry
hive is not possible.
A24. Network-mounted profile directories are impossible; per-terminal
storage is required.
A25. Logging in to multiple terminals at once requires making a local copy.
A26. A25 means changes to the network version don't propagate until
logout/logon.
A27. A25 each terminal that logs out clobbers the existing roaming
registry.  Last logout wins.
A28. Means A25 actually has to be done with all users logged out.  And
A18 means a reboot after logout is often needed, and best practice,
for same.
A29. Forget about cross-platform compatibility.

  And those are just the ones I have time to write about right now.

  To address Ric's example specifically, there's absolutely nothing in
there that couldn't be done in a simple file.  I know there are Python
libraries to give access to, say, an INI file, or even simple binary
storage.  Putting it into the registry instead has no benefit that I
know of.  None.  Zero.  Zip.  Zilch.  Nada.  Goose egg.  And if Ric
ever wants to, say, port his code over to a different platform (maybe
he gets new equipment or software, whatever), he's got one more
problem to worry about.

-- Ben