Hacker News Reader

Comment by jpablo | Hacker News Reader

I agree that the registry is a mess and probably badly implemented as well.

But a few of the criticism coming from the linked blog seems of the form "the Windows Registry is only compatible with Windows".

Since the Registry is very specific to the current version of Windows the user is running I don't see why, from a technical point of view, should effort be wasted in trying to make it more compatible with other platforms or versions of Windows.

The registry is an abstraction and there's only a few supported ways to access it (regedit, .reg files and the registry API basically).

View on HN

The linked blog has created an new way to access the registry that happens to also run on Linux. The larger project (http://libguestfs.org) aims to be able to make changes to virtual disks that comprise virtual machines without having to actually turn them which is pretty neat if the same registry tweak needs to be applied across a bunch of machines. But that explains why their new registry access api needs to be compatible with the various windows OSes.

Yeah, I saw that. My point is that the registry wasn't designed for that.

I'll be the same as complaining that the format of the /etc files is not well document, is not standard across different flavors of UNIX and everyone sticks whatever they want there.

It isn't really the same. Anyone that needs access to something in /etc can get what they're looking for without having the first pierce a difficult binary format. Deciphering what they get back is another issue, but typically it's just a text file, so you can generally figure out how to parse it if you need to.

Yeah--Why does it matter that the registry is endian-specific? Doesn't Windows only run on little-endian processors (x86, x86-64) or am I mistaken?

Is there any reason why a new version of Windows couldn't do away with the registry and create a layer of abstraction to allow programs in a "compatibility mode" to run normally but have its registry interactions translated to the new system? Wouldn't that be a similar principle to what Wine does?

It would mean that if you port windows to a large endian machine, then you can't share registry files (ie. as in roaming profiles). It's not as much about the file format as it is about the implementation (simply dumping C structures to disk). I think what the author is saying is that it's just a crappy implementation.

I don't think there's any way at all to share the whole registry file even in the same endian machine. It wouldn't fly anyway since it's very machine specific.

The way you'll share parts of the registry will be using .reg files, those are just plain text so could easily be read anywhere.

The windows-specific issues are probably a large part of the problems that happen when you try upgrading Windows versions, e.g. XP to Vista, Vista to Win7, and no end in sight.

Based on what the article points out, I would speculate that Microsoft spends a lot of energy trying to catch and fix all the ways the registry migration breaks when doing an OS upgrade. Not only is that is all wasted energy, it will never hit 100% success rate because there will always be something the porting engineers never saw in their systems.

Not to mention - the registry hive file is an internal data file for Windows; why would the author have the expectation that it would always have the same format.

Reply on news.ycombinator.com