Slashdot Mirror
Going Deep Inside Vista's Kernel Architecture
bariswheel wrote to mention an episode of 'Going Deep' on Channel 9 which takes a hard look at the architecture of Windows Vista. From the post: "Rob Short is the corporate vice president in charge of the team that architects the foundation of Windows Vista. This is a fascinating conversation with the kernel architecture team. It's our Christmas present to all of the Niners out there who've stuck with us day after day. This is a very candid interview." Topics discussed include the history of the Windows Registry, and the security/reliability of Microsoft's upcoming operating system.
...good old ini files are much more easy to use (i.e. copy around, fiddle and the like)
That will also make applications easier to port. Something Microsoft doesn't want. Registry is a good lock-in tool for Microsoft.
Businesses would never accept this kind of qualty from, for example, partners, suppliers, and so on...
Businesses in all markets accept this kind of quality from their suppliers and partners all the time. They don't like it, they scream about it, they change relationships because of it, but don't think that problems of the same scale don't constantly occur in businesses generally. I say this as someone who spent five years in plastic housewares manufacturing. Technology is not unique at all in this respect.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
It must be nice to have mainstream consumers for your main customers, rather than IT pros. You can sell 'em anything, and they'll never know it's crap, because they don't keep up with the industry
That's why I always skip all these "new Windows release" articles - they're pap. Usually just alot of mouth breathing over widgets and rather pedestrian implementations of mundane technology. Boring, and not very informative. Keeps alot of boring writers in jobs, though. Microsoft is like a 5 year jobs program for "IT Professional" writers that otherwise don't know their ass from their hat.
It's almost as if this MSDN interview of an MS executive on future MS technology is somehow MS related.
Well, it was precisely this sort of hype that kept Windows 3.1 at the forefront while an actual 32-bit operating system that would run existing Windows applications (better than Windows itself) actually existed. Microsoft, through various "computer" magazines (which were nothing more than MS shills), painted a beautiful picture of Chicago, through artists renderings and feature lists for features that didn't even exist. Of course, when Windows 95 finally arrived, it was a bug-ridden piece of crap, but the marketing onslaught and MS's corrupt ways of dealing with PC manufacturers destroyed OS/2. People actually willingly went for one of the most unstable operating systems that MS ever produced.
The world's burning. Moped Jesus spotted on I50. Details at 11.
In short, I'm convinced the registry doesn't require a separate implementation from the filesystem.
Designers (including Mozilla's) are entrenched in the idea that lots of tiny files are bad. Traditional filesystems and even api's to some extent aren't optimized for that. But Microsoft was in a different position, because the designers of the registry were in cahoots with the filesystem people (same company). Instead of inventing the registry, they should have optimized NTFS for config info.
You bring up an excellent point. Reiserfs will likely not be popular for at least a decade because apps must be written to support it. Since most people don't have reiserfs, any app that requires it will be quite unpopular. Windows has the same problem with NTFS. Since Windows cannot rely on having an NTFS filesystem available, having it store the configuration data would not help very much. Not only does NT (all current Windows versions are based on NT) have to be able to boot from FAT[32], but the APIs still have to work on Win9x. What they would end up with is just some config-optimized FS layer on top of the filesystem. Come to think of it, they could call it a "registry"...
Remember, FAT (like most old Unix filesystems) could not have more than 64k files (each taking up at minimum one sector) and directories are not stored in sorted order on disk. This means that putting every key in a different file would start to limit the number of other files you could put on the filesystem and cause config file access to be slow because you would end up with lots of files in large directories.
When the system boots it creates a copy of the systems configuration data (LastKnownGood), which is relatively easy because it involves just copying a segment of a file. If the data were stored in a hundred or more tiny files, making this copy would have a huge performance impact on boot-up.
The Unix answer to this question is to either hard code the information right into the executable (most binary installations must go in specific directories) or write out a file in some proprietary format, and that doesn't solve the problem that the registry was initially designed for -- to manage all of the components of a distributed object system (OLE) where none of the components needs to know where any other component is installed or what it can do.
Quite honestly, I think the registry is a good solution to the problem of where to store lots of configuration data. Unfortunately its growth has not been managed, and is now a mess. Still, doing a search in regedit for some configuration is much easier than trying to grep the filesystem for something.
dom