It’s quite popular to bash the Windows Registry in non-technical or lightly technical terms. I’ve just spent a couple of weeks reverse engineering the binary format completely for our hivex library and shell which now supports both reading and writing to the registry. So now I can tell you why the Registry sucks from a technical point of view too.
1. It’s a half-arsed implementation of a filesystem
It’s often said that the Registry is a “monolithic file”, compared to storing configuration in lots of discrete files like, say, Unix does under /etc. This misses the point: the Registry is a filesystem. Sure it’s stored in a file, but so is ext3 if you choose to store it in a loopback mount. The Registry binary format has all the aspects of a filesystem: things corresponding to directories, inodes, extended attributes etc.
The major difference is that this Registry filesystem format is half-arsed. The format is badly constructed, fragile, endian-specific, underspecified and slow. The format changes from release to release of Windows. Parts are undocumented, seemingly to the Windows developers themselves (judging by the NT debug symbols that one paper has reproduced). Parts of the format waste space, while in other parts silly “optimizations” are made to save a handful of bytes (at the cost of making access much more complex).
2. Hello Microsoft programmers, a memory dump is not a file format
The format is essentially a dump of 32 bit C structures in a C memory heap. This was probably done originally for speed, but it opens the format to all sorts of issues:
- You can hide stuff away in unused blocks.
- You can create registries containing unreachable blocks or loops or pointers outside the heap, and cause Windows to fail or hang (see point 3).
- It’s endian and wordsize specific.
- It depends on the structure packing of the original compiler circa 1992.
3. The implementation of reading/writing the Registry in Windows NT is poor
You might expect, given how critical the Registry is to Window’s integrity, that the people who wrote the code that loads it would have spent a bit of time thinking about checking the file for consistency, but apparently this is not done.
- All versions of Windows tested will simply ignore blocks which are not aligned correctly.
- Ditto, will ignore directory entries which are not in alphabetical order (it just stops reading at the first place it finds a subdirectory named B > next entry A).
- Ditto, will ignore file entries which contain various sorts of invalid field.
The upshot of this is you can easily hide stuff in the Registry binary which is completely invisible to Windows, but will be apparent in other tools. From the point of view of other tools (like our hivex tool) we have to write exactly the same bits that Windows would write, to be sure that Windows will be able to read it. Any mistakes we make, even apparently innocuous ones, are silently punished.
Compare this to using an established filesystem format, where everyone knows the rules, and consistency (eg. fsck/chkdsk) matters.
Writing sucks too, because the programmers don’t correctly zero out fields, so you’ll find parts (particularly the Registry header) which contain random bits of memory, presumably kernel memory, dumped into the file. I didn’t find anything interesting there yet …
I also found Registries containing unreachable blocks (and not, I might add, ones which I’d tried modifying). I find it very strange that relatively newly created Windows 7 VMs which don’t have any sort of virus infection, have visible Registry corruption.
4. Types are not well specified
Each registry field superficially is typed, so REG_SZ is a string, and REG_EXPAND_SZ is, erm, also a string. Good, right? No, because what counts as a “string” is not well-defined. A string might be encoded in 7 bit ASCII, or UTF-16-LE. The only way to know is to know what versions of Windows will use the registry.
Strings are also stored in REG_BINARY fields (in various encodings), but also raw binary data is stored in these fields.
Count yourself lucky if you only access official Microsoft fields though because some applications don’t confine themselves to the published types at all, and just use the type field for whatever they feel like.
And what’s up with having REG_DWORD (little-endian of course) and REG_DWORD_BIG_ENDIAN, and REG_QWORD, but no REG_QWORD_BIG_ENDIAN?
5. Interchange formats are not well specified
A critical part of installing many drivers is making registry edits, and for this a text format (.REG) is used along with the REGEDIT program. The thing is though that the .REG format is not well-specified in terms of backslash escaping. You can find examples of .REG files that have both:
"Name"="\Value"
and
"Name"="\\Value"
In addition the encoding of strings is again not specified. It seems to depend on the encoding of the actual .REG file, as far as anyone can tell. eg. If your .REG file itself is UTF-16-LE, then REGEDIT will encode all strings you define this way. Presumably if you transfer the .REG file to a system that changes the encoding, then you’ll get different results when you load the registry.
6. The Registry arrangement is a mess
Take a look at this forensic view of interesting Registry keys (PDF). List of mounted drives? HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices. But what the user sees is stored in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume\. Unless you mean USB devices which might be in the above list, or in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR. And the entries in those lists are by no means obvious — containing impenetrable binary fields and strange Windows paths.
If you browse through the Registry some time you’ll see it’s a giant accreted mess of non-standardized, overlapping information stored in random places. Some of it is configuration, much of it is runtime data. This is a far cry from /etc/progname.conf in Linux.
7. The Registry is a filesystem
Back to point 1, the Registry is a half-assed, poor quality implementation of a filesystem. Importantly, it’s not a database. It should be a database! It could benefit from indices to allow quick lookups, but instead we have to manually and linearly traverse it.
This leads to really strange Registry keys like:
\ControlSet001\Control\CriticalDeviceDatabase\pci#ven_1af4&dev_1001&subsys_00000000
which are crying out to be implemented as indexed columns in a real database.
8. Security, ha ha, let’s pretend
Despite the fact that the Registry is just a plain file that you can modify using all sorts of external tools (eg. our hivex shell), you can create “unreadable” and “unwritable” keys. These are “secure” from the point of view of Windows, unless you just modify the Registry binary file directly.
Windows also uses an unhealthy dose of security-through-obscurity. It hides password salts in the obscure “ClassName” field of the Registry key. The “security” here relies entirely on the fact that the default Windows REGEDIT program cannot view or edit the ClassName of a key. Anyone with a binary editor can get around this restriction trivially.
9. The Registry is obsolete, sorta
Well the good news is the Registry is obsolete. The bad news is that Vista has introduced another, incompatible way to store application data, in AppData/Local and AppData/LocalLow directories, but that Windows Vista and Windows 7 continue to rely on the Registry for all sorts of critical data, and it doesn’t look like this mess is going to go away any time soon.
* * *
libguestfs on Fedora now provides the tools you need to manage the Registry in Windows virtual machines. For more details, see hivexsh and virt-win-reg documentation.
Update
Thanks to all who commented. There is further discussion here on Reddit and here on Hacker News (including discussion of inaccuracies in what I wrote). If you want to look at our analysis code, it’s all here in our source repository. For further references on the Registry binary format, follow the links in the hivex README file.
Richard WM Jones 
> 5. Interchange formats are not well specified
Frankly, anyone writing a driver who’s even slightly sane (and I really hope he’d be) would use the registry APIs and not .reg files.
> 8. Security, ha ha, let’s pretend
Hm? Who cares about the security of a salt?
> 9. The Registry is obsolete, sorta
Vista didn’t introduce anything fundamentally new there — it just renamed Application Data to AppData\Roaming and Application Data\Local Settings to AppData\Local. LocalLow is new, but that’s needed to isolate low-integrity processes.
Registry supports indexes in the same was many databases do. Reverse lookup tables. If you need something indexed then you create a key and store values in that key. It wasn’t designed to be scanned/searched as that is not useful from a high performance targeted persistence store. And btw, go search for a value across all of the files in etc, dev and var your performance will suck too and you don’t have any indexes.
I disagree on many of your points. But the main problem is that you don’t suggest any alternatives.
/etc/*
Actually he suggested 2 alternatives:
1) A (non-half-arsed) File system
2) An indexed database
Are you kidding? He suggests, implicitly and explicitly, all sorts of alternatives:
Don’t use a filesystem, use a database.
Make the format checkable and consistent.
Define data types (better than they are now).
Define an interchange format.
If you’re going to implement security, don’t just pretend to do it.
@Stev Hanov:
he does not have to suggest any, he has implemented a library to edit it and as such has learnt probably more than he wanted about the registry. Those are his conclusions.
Richard, thank you for writing this. Long ago I was a nerdy young programmer in the audience at the first Microsoft Windows NT development conference and in the Q&A for the presentation on the new Registry feature, I spoke up and asked about whether there would be metadata available as part of the registry API. I was trying to suggest that it wasn’t enough to just provide an arbitrary dumping ground for data of any type, but that there must be a way to get information about the precise format of each entry. I was also thinking about the importance of tools to browse and clean the registry, which would require knowing how to display each piece of data to end users. The model I had in mind at the time was Apple’s resource manager. This idea didn’t seem to gain any traction at all, but I still believe I was correct, and the lack of clear metadata was a design flaw that has led to endless messes.
Unfortunately the use of config files stored in the real file system don’t entirely address this issue, but an admin has at least a slightly better chance of figuring out what is in there, especially if the files aren’t obfuscated for “optimization.”
@Steve: he does suggest /etc. And I would add gconf.
Actually a speed+size comparison of registry vs. gconf may be worth the effort.
gconf is only marginally better, and only because it’s less ancient. I’ve seen apps serialise whole xml files and store them in a gconf string for example (serialise because xml in xml does not work, you need to replace brackets with something else).
The problem with gconf, and the registry, is that their authors didn’t bother with strong use policies. They rejected old configurations files as inconsistent, but instead of defining conventions everyone should follow they proposed a mechanisms expecting conventions to emerge naturally.
That was hopelessly naive. Developers just saw a convenient persistence layer they could dump anything they wanted at, obscure enough for no one to complain.
Oh dear,
I never had *any* issue with the registry
other than I didn’t find a key in the first place.
And, it is not a filesystem.
It is key/value store with metainformation
for hierarchie and security information.
It is really often seen that a file format is a direct
“memory dump”, a 1:1 mapping of C struct.
Sybase, SQL Server, Oracle, PostgreSQL, they all do it. Why ? Because mmap()ing a file is dead simple and backed by attomic behaviour and copy on write semantics by your OS.
There is no need to write a dump/load routine,
it’s there.
Where is the problem ?
The registry was *never* my problem under windows, not in 18 years …
And exactly why is /etc better ?
And what made SUN choose to implement some
of these /etc files as SQLite databases in favour ?
And, isn’t this even *only* a memory dump ?
Oh dear, oh dear.
You made me waste my time …
So you think it’s a good idea to base your operating system fundamentally on a format which can easily be corrupted and where you can hide data? Which is not fully understood even by the developers? Where the content of fields is not well-specified?
Again: the registry was never a problem.
It works. As expected 🙂
We are talking basically of a key/value store,
where type information is of minor interest and
it is more up to the application to interpret
it correctly which wrote the data.
(Would you feel better if everything was a string ?)
Everything else is what it is: doing what it should.
Sure, there are technically better implementations of that kind of store.
But, who cares ?
It has no network interface, it is reliable (i *never* saw a broken registry, has simple operations and is fast enough (don’t use it as a mp3 store…)
In response to Stefan @ 8:05, here’s the network interface for the registry:
http://msdn.microsoft.com/en-us/library/cc244877%28PROT.13%29.aspx
Used by this software (at least): http://msdn.microsoft.com/en-us/library/ms894590.aspx
“The registry was *never* my problem under windows, not in 18 years”
Well, in my 8 years as tech-support I dealt with at least ten machines (about 100 wintel machines at that place) that wouldn’t boot due to corrupted registry hives or errors in the registry itself.
On top of that; performance issues, applications misbehaving due to registry issues… Granted everyting got better with XP, but the problems continued.
Conclusion: Even if it never caused you (discernable) problems, it has caused others.
I don’t understand the registry well, but I do understand PostgreSQL fairly well.
Yes, C structs are written directly to disk and read directly from disk, and are thus machine specific (although each type must define textual in/out and optionally a binary send/recv pair that are not machine specific). Data types are informed by the catalogs. This design is not dissimilar from many other RDBMS.
The author seems like he/she would understand this, so I ask: compare and contrast.
There’s one difference I can think of.
RDBMSes exclusively maintain their datastore. Arbitrary userspace programs are not able to mess about with that store. Not so with ntuser.dat .
I’ve had 3 Vista installs and at least 2 XP installs damaged due to registry corruption. The effects are always fairly random: on one install Event Viewer and several other windows services would not load; on another install it just stopped booting one day, getting stuck on the splash screen with the progress bar continuously moving.
I traced all of these incidents back to unsafe shutdowns of the computer. As there were no error logs, or backups of the registry, I couldn’t trace the corruption to an exact location or replace the registry with a non-corrupt version. On average it took about 8 hours per incident to find the problem, realize it is unfixable and reinstall windows & every registry-dependent app.
If the registry was a proper database with ACID properties, this wouldn’t have happened. If this was a collection of files like /etc/*, then the effects of corruption would have been isolated and the affected files could be directly replaced.
It is unavoidable if you have unstable power or are prone to kernel panics, and it’s very expensive to fix as it almost always requires a full system reinstall. So yes, it is a HUGE problem.
I agree. It is a huge problem. I’ve had my fair share of registry issues. Or unfair, depending on your perspective. Once, as far as I can tell, simply by installing a Blu-Ray burner. I deal with it by using ERUNT to make regular registry backups and keeping a Ubuntu Live USB drive handy. I also image my system and application drives every year or so.
Let me translate this for you:
“Waaaaahhhh, I like linux.
This program has constructs that I dont understand so I’m going to call them bugs.
This should be written more linux. /etc is great, and nothing can ever be hidden there. No software that uses /etc could have a bug. Windows sucks because its not like linux.”
I’m afraid you are quite wrong. If you would just read the article, you’d find out why you are wrong.
So true. The majority of these same problems exist in /etc such as no indexes and the performance of trying to scan /etc is as bad or worse… though like the registry wasn’t designed or intended for that function. (At least the registry has a single fixed structure versus being a mix of scripts, markup and persisted binary.)
The argument isn’t that /etc is perfect. The argument is that the registry is a Frankenstein’s monster of a filesystem and a database that manages to combine the flaws of both.
If they’d stored a tree of files in FAT32 or NTFS, for example, then all the effort poured into tools like chkdsk and less fragile drivers would just translate over, and a write error in a specific application’s configuration subtree wouldn’t corrupt the system boot configuration.
It doesn’t necessarily have to follow that you also go plaintext, but the rationale for UNIX was that the pros of manually repairing them after a crash outweighed any cons. Take that for what you will.
Alternatively, if they’d gone all-in on database-style, they could have ACID compliance so that crashes couldn’t corrupt the registry, indexes, and so on.
What matters isn’t whether
/etcis good, but that the Registry is worse on a technical level when it would have been easier to just cobble together something more robust using NTFS permissions (remember that Windows 9x doesn’t have privilege isolation anyway), INI files, and the same design they used to map the Start Menu to a folder.I think the author has expressed many valid arguments in this article, and find it quite frustrating that someone would take some of their precious time to rant about the time they “loss” reading it.
The registry is a requirement of the real purpose of windows, a massive data collection system. Its the one stop place they can go to know everything about your system.
I think you are ignoring one of the critical design requirements for Windows, just as for the IBM line of mainframes. These systems must work well, but must be very difficult to clone (reliably). The Windows registry is one of several critical systems where you can never be quite sure you have cloned it all, as I’m sure you realize now. Yes, from the outside the engineering appears sub-optimal, but from the business perspective the architect has built a rather defensible barrier to their effective monopoly.
Some of these responses are fascinating. If anybody carefully reads this blog post, has any sense of how deeply dependent Windows is on the registry and doesn’t come away horrified at what a mess Redmond hath wrought, then they’re either terribly naive, woefully ignorant or willfully oblivious.
The “Application Data” profile folder has been around since NT4 – this common alternative to storing application-specific data in the registry is nothing new.
you’re going too far into the insides of the registry and forgetting the concept of the registry. If the registry is corrupted, the system is screwed! not much else needs to be said
@roarke, the point is, in any competently designed system you minimize the number of single points of failure involved, starting with the potentially most critical failures as well as the SPFs which can be most easily eliminated. The continuing existence of the Registry fails on both counts.
Don’t look at it as a Windows vs. (other system) issue; look at it as what it is — an egregious defect that eliminates any possibility of reliable, secure, verifiable operations over time, especially in a large-scale environment. How long has it been since NT came out? I think that qualifies as “operations over time,” don’t you? And, since most Windows use occurs, and problems are detected in, corporate environments, we’re necessarily talking about a “large-scale environment” relative to individual home usees.
Just imagine how different everything about using PCs — up to and including the effect on society in general — would have been had Microsoft brought out a consistent, well-designed and -implemented, secure, reliable system instead of NT 4.0+, XP, Vista, and 7. No malware. Dramatically smaller network-security threat envelope. Improved productivity and lower support/training costs because the system was actually designed to be used, rather than merely to be sold.
Instead, we’ve had a generation of computer users severely limited by the negligent defects in the software they’ve had rammed down their throats, and, far worse, another generation of people who’ve been taught that’s a Good Thing because they’ve never seriously thought things through.
It is all relative. I Only support Windows, I am not a big fan of much of what is implemented or half implemented. However to all of those who are experienced in windows and all of those who have used /etc/App_Name.config or even the mac ~/Library/Preferences/App_Name.Plist which is another Key-Value store – – If you havent tried this then you miss the advantage of zipping a .conf/.plist and editing it with zero chance of affecting other apps that are working well.
in the end most of ‘us’ will not take a system to fubar but ‘It works for me’ is not the same as it isn’t broke
someday there will be something better and we will laugh
Great and informative, followed by moronic comments 🙂
as a sort of aside: how is the fedora community on reddit? existent? non-existent? flourishing with ponies? 🙂
There is a Fedora Reddit. I’ve never looked at it before until right now.
Most of the Fedora action seems to happen on the Planet (and of course on all the mailing lists).
back when windows 95 introduced the registry, it was touted as the best way to store configs, compared with the windows 3.1 way of storing configs in .ini files….
As I recall, the Windows API calls that dealt with reading and writing the registry had a flag that would change it to working with .ini files instead. This was NT3.1-era, IIRC. Perhaps keeping that backwards compatibility (that is, data that could be stored in the registry had to also be storable in .ini files) is part of what caused *some* of these problems.
Excellent post Rich. The idea that the registry should have been a proper database occurred to me as well. I’ve seen countless problems with reliability issues related to registry corruptions that would have never happened with referential integrity checks with a RDMS. Sadly, backwards compatibility experts at MSFT would argue strongly that changing the registry to a RDMS system for *any* future Windows versions can’t be done since it would break too many old obscure programs that customers expect to work.
To the blog guy:
What you’re looking at is likely the serialized representation of a text or xml format. That is not to be reverse engineered, there are likely well defined input and output routines in Windows for storing the registry to disk. Now, I like to bash MS as much as the next Linux guy, but there are public APIs for accessing the registry. Use those and shut up. Otherwise, what you’re asking is for MS to open source their serialization code, and you really shouldn’t be asking for that to happen because you know it’s not going to happen.
[Meta-comment from the “blog guy”] I thought I’d include this comment instead of just deleting it as a good example of people who don’t read the article before posting. Lots of people only seem to read the title, or in this case, only the first 5 words of the title.
The registry may suck, but not on this evidence.
The fact that you can use programs to tamper with the files in non-standard ways to hide data does not mean that the registry “sucks”. Within Windows, the files are locked open, and for the most part the only way to modify them is to use the appropriate APIs. This means: no corruption, no secret data, no bad ordering of B-trees, no skipping ACL checks, etc..
I daresay I can fuck around with ext2/ext3 filesystems in such a way as to hide or obscure data such that the proper ext2/ext3 drivers cannot use it–does this mean that ext2 and ext3 also suck?
DrPizza
I believe the difference is that you know how you *should* be writing ext2/ext3/ext4 drivers–the system is documented well and things are designed consistently. Yes you can make bad data–but you are discouraged from doing so.
Trying to write a compatible ext2+ reader/writer is fairly easy–I count at least 3 for Windows last I checked.
Trying to write a compatible registry reader/writer is very difficult.
Pingback: virt-inspector now works better with Windows guests « Richard WM Jones
Pingback: GLLUG talk on libguestfs (18th March 2010) « Richard WM Jones
Man, you can sure tell who the Microsoft whores are in the replies.
Pingback: Use hivex to unpack a Windows Boot Configuration Data (BCD) hive « Richard WM Jones
“A. Lester Buck III
February 19, 2010 at 12:39 am
I think you are ignoring one of the critical design requirements for Windows, just as for the IBM line of mainframes.”
that comment is all one needs to understand the registry. everything else is shills and zealots..
^_^
cheers,
-m
I’ve already tired with this registry. Why MS still implemented this on 7?
Fortunately, I’ve already jump to the next ship.
Pingback: Windows SAM and hivex « Richard WM Jones
The registry is stupid. Many things are stupid in Windows. Settings are scattered all over the place. Some programs store settings in the registry, some in various deeply nested hidden folders, and some in the installation folder itself in an .ini file.
I use Windows mainly because there are no Linux drivers for the hardware I use for my work, but having used Linux in the past I can assure you that things make a lot more sense the Linux way. Everything is much better structured and tidier. To begin with, most configuration files are human-readable. The registry is a complete mess. Every uninstalled program leaves traces of crap behind, and there is duplicated/overlapping crap all over the place, like the original poster pointed out.
Even well known, well published, successful and respected Windows Hackers agree with this Linux Hacker’s article.
For example…
http://www.codinghorror.com/blog/2007/08/was-the-windows-registry-a-good-idea.html
None of the “Registry Loving” commentors have provided technical counter arguments that meets the same level of Software Engineering credibility that this blog post does…
After reading the entirety of this article all I could think is that the author really was clutching at straws when trying to knock windows. It sounded like the hyperbole of someone who already knew their conclusions before investigating the evidence. Infact it felt analogous to reading a revised article about the technical failings of a maseratti written by someone whose only experience of them is when they drive past him at 200mph.
I have used nothing but Linux for the past two years , in a personal capacity, and in my work I maintain both windows and Linux servers. I prefer Linux servers but there is something to be said for windows both as a desktop and a server. The registry has never presented a problem at all, since windows makes multiple copies of the current registry and previous versions so that a rollback can be made and the machine boots from an earlier version. If windows boots and works whats the problem?
So you dont like its methodology? oh well they havent offered you a contract of employment so dont worry about it.
Trying to alert others of the great and most imminent danger they are in? Hmmm well you know the market makes up its own mind and if the windows registry was such a huge problem business would suffer, directors would question, heads would roll, and better technology would be employed. the fact that industry runs on windows is testament to its suitability.
why dont you do some real research that is based on accurate observation rather than dogged dogma and assumption?
The windows registry simplifies the process of repair and organisation of information. You are simply being misled if you think any other operating system is easier to repair than windows, as I said, my experience is with windows and Linux and although I admit the bigger problem is in keeping windows machines running, by far the easiest to fix when things go wrong is also the windows machines. Thats all i want to know, whats easiest to run and repair.
You’re an idiot.
Easiest to run and repair? Windows has been the most patience-wearing operating system since at least since 3.x series. I’d rather be running an Apple II-e. I’ve spend more time cleaning up people’s registries and file systems, many attempts of which fail entirely multiple times because of windows’ horrible task scheduling. Just to power on a windows computer makes me regret agreeing to look at, let alone attempt to diagnose or repair, anything at all. Even a windows virtual machine I have had caused me enough grief as to trash it at least once.
Furthermore the popularity of windows is a testament to marketing. Note the tendency of computer game publishers to target windows. It is an effective business scheme on the part of Microsoft to purchase exclusive rights from a game publisher. They do this with consoles, even. How many games over time have only come out on the sega, on a nintendo, on an xbox, singularly. As well, one could say it’s a testament to how easily people can be duped into buying such a system that they believe is the best if not only option. You pratically have to buy barebones just to get a PC without windows, unless you want to go the Mac route, which is expensive. Furthermore, windows often preloaded, so buyers are led to believe that a system will just work, as-is, and require no real maintenance. A person has to download and/or auther special programs to do trivial maintenance tasks in windows that happen naturally during the shutdown and/or boot-up of a GNU/Linux, BSD, or even Darwin(Mac) box, or at least to do them effectively.
Also, the fact of having been offered a job at a place, does not make its products or services of better quality, it just means they probably have you by the bollocks with plenty of non-disclosure and anti-defamation clauses that could cause you even more grief than to just be terminated and sued. The sheer fact that you would so adamantly defend something like windows is horrible enough, but to spend so much time insulting someone who, like it or not, put forth many valid arguments and sane reason, only proves your ignorance.
In short:
Do some of your own damn research, or at least make better points, (any valid ones?) before you spew this much tripe in a comment thread, please.
You spent a lot of time cleaning up peoples’ registries because those people have no friggin’ clue what they’re doing with their computer, and they tend to screw things up. I’m not saying the registry is an amazing thing, because it’s not… just that it works well enough in the hands of a techie who understands everything they are doing on the system.
If you take the same idiots who gunk up their registries in Windows and sit them in front of a Linux system instead to use every day, you can be sure it isn’t going to take long before they’ve broken that too.
Windows has quite a few pros to go with it’s cons. There are a lot of computer nerds that really know what they’re doing that like Windows as a desktop OS. Linux also has pros and cons, and while I do use Linux a lot, every single day and know what I’m doing (I’ve even contributed some of my own code to the Linux kernel on a couple of occasions) I still kind of prefer Windows as a main desktop workstation OS.
For me, Linux shines brightest as a server OS. It’s capable as a workstation OS too, but IMO Windows is generally smoother and a bit less of a hassle for it. To each his own. I’m not saying you should use it, but the real hardcore Linux geeks won’t even acknowledge it’s numerous good points and the fact that there really are use cases where it’s technically superior.
A database would be overkill – the registry is only meant for Key-value storage.
I often wonder why people comment here who obviously have not read the article.
Well I’m just a plain user with a small business. The registry is for me a central point of failure. With hard drive failures the registry can become corrupt and then it’s drama for me. Also I would like to install my programs on other drives than C. It’s easier to repair the other drives. Having to rebuild a c drive with all the programs on it is not fun. The registry does not make it easy to relocate programs. Programs are now scattered all over the place. In a perfect world I think the registry is ok but in the real world not so practical.
Andy, you’ve hit on one of my decade-plus major malfunctions with Windows. Sound sysadmin practice since the dawn of mass storage on computers has found that installing the operating system on one partition, applications on a second and user data files (documents) on a third is the best way to organise a system. This makes backup and restore more granular and fail-safe and allows for the different partitions to be on different physical drives (subject to the limitations of the OS), and so on. It’s not uncommon to have the first two (system and apps) write-protected except during deliberate updates. This also guards against system damage, either by operator error, software fault or malicious attack. Every single hard-disk-based OS I have used in the past 30+ years has supported this out of the box… except Windows.
To make Windows Do The Right Thing, you have to burn your own install DVD/CD. This is something that Joe Average simply can’t be expected to know how to do, and consequently, won’t do. This leaves the barn door several parsecs more wide-open than necessary. In fact, out of perhaps 200 Windows PCs I’ve installed this way over the years, only one is known to have been compromised — and that was through a rather neat bit of social engineering that overrode any possible technical protections.
I’ve been saying since the early ’90s that one of the best indications we’d ever have that MS was getting serious about security and stability would be if they used this sort of a scheme as the default. With the standard directory structure in Windows NT and later, it wouldn’t be at all difficult for them to do.
This may be of interest…
The Windows NT Registry File Format v 0.4, Timothy D. Morgan, 2009
Click to access TheWindowsNTRegistryFileFormat.pdf
Many who recall and/or use Windows NT 4.0 would know about the beloved ERDs (emergency repair disks) – these things were encouraged heavily by Windows especially before installation of a service pack or whatever.
But they would store entire copies of the registry on them. Install a few programs and you will fill up your disk. And therefore will not be able to successfully create an ERD at all.
It is bad enough to have a few large files to store all the system settings, settings for all applications, and user specific settings in there. It just makes backing up difficult.
And in more modern versions of Windows the problem is escalated further when it creates *.LOG/*.LOG2/*.REGTRANS-MS/whatever on your drives.
What would have been a much better idea is to have a library which allows apps to work on their own individual hives and document their format. It would basically make backing up easy too sine then you would only have to worry about the files you need for configuring the basic system.
Along with this there is potential for an optimization API too so that applications can periodically optimize their configuration databases. One would use REGEDIT to edit the application’s config databases much in the same way one would edit a text file using Notepad then.
There is only one reason the registry exists. That reason is… it allows Microsoft to make more money. That’s all Microsoft cares about.
It does this by controlling what the user can and cannot do (making copies of programs installed, and/or backups easily), and by acting – quite intentionally – as a central point of failure. A damaged copy of Windows must be repaired or replaced, and they make money every time someone without a clue buys a new computer because of a corrupt registry.
They also make money if someone buys a copy of Windows install disc to re-install. And of course then there’s those wonderful certifications they push to teach some poor fool how to fix it. If it can even be fixed.
The registry is as ridiculously bad a system as it is because it is easily damaged, etc. etc. That’s a feature, not a bug. It just happens to be a feature that only benefits Microsoft, that’s all. Users? **** ’em. They’re just cash cows.
I would respond to the comment above that “the market decides” with the reality that Microsoft has successfully manipulated the market such that it only decides what they want 90%+ of the time. That’s kind of killing your lame argument.
Do I use Linux? You bet. Mainly because my “Geek Squad” days (long before there was one) are long past, and I have a business to run, instead of money and time to waste on Microsoft’s BS. Thank God for VMs, because now when I am forced to run Windows, I can just hit “revert to snapshot” whenever the registry suicides. Which it has done about five times in the last four years for my XP install, by the way.
Pingback: [theory] Microsoft attempting to replace the registry? - Windows 8 Forums
Can any program write to any part of the registry? Are there permissions and mechanisms to prevent that happening?
Pingback: Postcards From Linux Part 4: Stuff I Can’t Do - Twenty Sided
More over-under-over-engineering by Microsoft.
Pingback: hivexfs | Richard WM Jones
Mostly good points. I don’t see how it being endian-specific is an issue, though. It’s not like anybody is moving sections of their registry from their x86 PC to say, Windows RT on an ARM.
As a (former) volunteer techie for a non-profit running a cybercaf lab of PCs (running MS Win9x then MS Win XP) for the local community (ended with Sept 4, 2010 earthquake, Chch, NZ), I’m afraid I have to second you on this. The worst thing about the registry in my experience, is that Windows doesn’t do a very good clean up when you delete an installed file. When you’ve deleted some malware that’s written to the registry then find it’s back again, due to something hiding in the registry that reinstalls it, it can get a bit much. On occasion I had to go registry-diving on my own time to find fragments of uninstalled files’ configuration to manually hack them out. Lotsa fun! NOT!
I find the article quite fair in its assessments and make some good points. There are much better ways of handling this kind of data and settings and I don’t see way there are so many people on here with the attitude of “I haven’t seen or lack the knowledge to notice problems so it’s great and your a big stupid doody head!”.
If one prefers windows as their platform for one reason or another that is fine; however if that individual says they find the registry acceptable in it’s current state then that person does not know what they are talking about. That person is known as a fanboy, defending all aspects of their product of choice including it’s flaws to feel as if they justified their used of it.
That would be comparable to me saying “I like the taste ice cream and I also like how it makes me fat”.
You can love a product and certain aspects of it at the same time because nothing is perfect.
That being said, they way windows handles most settings, configurations and system files is very inefficient and cluttered in several locations. An example of clutter and disorganization would be the user folders, the windows folder and the system/system32 folders.
It is not just the registry that needs to be revamped.
Sorry if my english is lack luster, I just started learning a few weeks ago.
What an awesome tear down of the Windows Registry.
I often wondered why this monumental piece of garbage was foisted on us.
Now I fully understand why its so bad.