Linked by Thom Holwerda on Fri 30th May 2008 14:49 UTC
Windows We have learnt quite a lot about Windows 7 this week, and one of the things was that Windows 7 would not get a new kernel. The call for a new kernel has been made a few times on the internet, but anyone with a bit more insight into Windows' kernel knows that there is absolutely no need to write a new kernel for Windows - the problems with Windows lie in userland, not kernelland. While the authenticity of the Shipping Seven blog is not undisputed, the blogger makes some very excellent points regarding the kernel matter.
Thread beginning with comment 316432
To view parent comment, click here.
To read all comments associated with this story, please click here.
ashigabou
Member since:
2005-11-11

The registry is an important subsystem of the kernel, but it is significantly harder to corrupt and more suited for its purpose than using flat files.


I don't see how you can say it is harder to corrupt: if the registry is corrupted, you simply cannot use windows anymore, you have to reinstall it. Difficult to have easier to corrupt: that's a single point of failure. Which is certainly not the case of /etc. The goal of the registry was to have a single place to handle configuration, but it was because windows did not have a sane way to store configuration (one directory for the system, and $HOME/.foo directories for users).


The equal statement to this fellow's assertion is "the /etc/ tree has to go!" I don't think either of those statements is true.


No, it is not: the problem is not using configuration in a centralized manner, the problem is the implementation of the registry, which is horrible (binary, keeps growing, etc...). But this is arguably a complex topic: /etc is certainly limited once you want to manage many machines in a large network, and it is a shame that every software uses its own configuration format (with different behaivour related to escaping, etc...). The .ini is actually often enough for simple applications. To solve the network adminisation problem, Solaris and mac os X for example have their own way to deal with it in a centralized manner. But /etc is still there.

Anyway, this has not much to do with the kernel.

Reply Parent Bookmark Score: 2

PlatformAgnostic Member since:
2006-01-02

It has to do with the kernel because the registry implementation is in the kernel, and it is used by the kernel quite early in boot.

The registry is essentially a specialized filesystem. So it's a single point of failure inasmuch as a filesystem is a single point of failure. The binary format of the registry is pretty much analogous to the format of a filesystem as well (it's a journalled, transactional data store with per-key ACLs, symlinks, etc). It's actually implemented in multiple files, and the per-user portions of the registry are stored in separate user hives in the home directories (I think the specific file is ~\ntuser.dat). The system-wide hives needed for booting and managing drivers have backups taken when you make config changes (the "Last Known Good Configuration"), so if the current hive file becomes corrupt due to disk problems, there's a chance of recovery through the backup files in %windir%\system32\config\regback. I'd say the registry implementation is not so horrible.

Have you had any specific problems with the NT registry? I have no idea what the inside of the 9X registry was like, so perhaps your complaints were justified in the past.

Reply Parent Bookmark Score: 2

ashigabou Member since:
2005-11-11

It has to do with the kernel because the registry implementation is in the kernel, and it is used by the kernel quite early in boot. [/quote]

The registry really is implemented in the kernel ? The fact that it is used by the kernel early in boot does not mean it is linked to the kernel. Well, it depends what you mean bu kernel, then. /etc is used early in the booting process (to know which driver to load/not load, for example), and it has nothing to do with the kernel.

[q]
The registry is essentially a specialized filesystem. So it's a single point of failure inasmuch as a filesystem is a single point of failure.


But that's exactly what's bad with the implementation: (a fs) means that the configuration became a single point of failure. Also, having to reimplement all this as a fs is kind of stupid: why not using the FS for this ? This gives you more fine grained control (ACL are per key, right ?), but I fail to see how this is useful. This has never been useful on any other OS (and


I'd say the registry implementation is not so horrible.


The fact that it is not documented (applications put way too many things in there and cannot work when it is not there anymore; arguably not the fault of MS here, at least not directly), keeps growing is enough for me to say the implementation is quite horrible.


Have you had any specific problems with the NT registry?


All the time when I have to use windows to build software for windows. In particular, uninstalling an application always leave garbage in the registry, which is annoying when you install a new version of the same software (visual studio comes to mind: install visual studio 9 and 8 has still keys there, which confuses many softwares).

And it also means it does not work at all to reinstall the OS without reinstalling all the applications, even if they are still there: all the path informations about the software are again in the registry, which means nothing is self contained.

Reply Parent Bookmark Score: 1