https://rwmj.wordpress.com/2010/02/18/why-the-windows-regist...
Actually you can use the Windows Projected File System to project the registry into the file system, making registry keys and values appear as files and directories.
https://github.com/Microsoft/Windows-classic-samples/tree/ma...
Like for example, you already point out how the type system in the registry is very limited. But isn't the filesystem even worse? Everything there is binary blobs with no types at all. So how does that improve things?
It seems like your complains don't really have to do with the "directory" structure of the registry much, so I don't think moving to a file based model would really change anything. You'd just end up with the same legacy issues, but spread across more files.
Finally, AppData wasn't introduced with Vista, but rather it's always been there if applications need to store file-based data rather than individual configuration values. That is not a new or improved way of doing things as you seem to imply in the post.
NTFS specifically has file forks ("Alternate Data Streams") and I guess you could use those to store a type, although whether using forks would be a good idea or not is up for debate.
If those types aren't enough for your use case, then you will be forced to roll your own types in some binary/string data anyway, so it seems like it's strictly more work if you just always force everyone to roll their own.
And even then you still end up with the possibility of people using the wrong syntax for your hand-rolled types, like not quoting values that are supposed to be strings or quoting values that are supposed to be numbers.
Besides, wouldn't it be easier to fix this just by adding some more types, or deprecating everything except REG_SZ or something? What's the advantage of moving to a directory based model?
File-based configs on Linux have the same problem anyway. The semantics of any config file you find are defined by the application that's consuming it. Any two config files that superficially seem to be using the same format, may in fact use a completely different one - and you'll never know, up until you edit one and it blows up in your face, because it cannot parse empty lines or #-comments, or escape characters, or negative values, or values larger than 2^16, or...
Whether altering Windows registry or a Linux config file, you cannot make a correct modification without knowing what the owners of the modified settings expect.
how does this amaze anyone? how do people think backwards compatibility works?
Microsoft, supporting Windows, promises to make every effort to maintain backwards compatibility wherever possible so that programs compiled for, say, Windows 95 will run unmodified on Windows 10.
Not every program from 20+ years ago runs, but a lot do! That's a very hard thing to do if you wish to continue to advance the technology you use in your operating system. Apple doesn't even try.
Microsoft have taken steps to break backwards compatibility a few times in the name of progress and every time I talk to people during those transition periods, it is a 50/50 split between people who don't know that they've been given a decade of notice and now their "tried & true" software development paradigm doesn't work anymore, and people who are angry because most of the old ways are still supported.
The registry wasn't even supposed to be what it is today. it was a small stop-gap thing to stand in place while a better solution was developed. Developers discovered it, started using it, and now Microsoft has to support it. Of course it's rubbish; metaphorically, it's a piece of a whiteboard used as a doorstop until the real doorstop is delivered, except for some reason people started using it for important stuff and now everyone needs it.
That doesn't have anything with backwards compatibility. Nothing forces MS to stick to old ad-hoc memory dump format. Neither there is anything that would suggest registry is deprecated, new Windows components keep using it and adding piles of junk into it.
if everyone used the API, then yes you're correct. in my opinion, Microsoft should do what you stated, but they don't want to, out of fear of breaking backwards compatibility for people who do the wrong thing. their needs are just as valid as yours or mine.
Most of the actual technical issues you list have more to do with it being extended for the last 30 years in a backwards compatible way than anything to do with it being a hierarchical db instead of a filesystem.
http://reboot.pro/topic/7681-the-registry-as-a-filesystem/
https://web.archive.org/web/20090413131629/http://czwsoft.dy...
https://web.archive.org/web/20140401212651/http://pasotech.a...
And:
Regardless the point wasn't "a filesystem couldn't represent a rewritten registry" it was that the registry is actually a database today (whether viewed as a file-system like db by the reader or hierarchical db it is listed as) and the rest of the technical problems have to do with it being 30 years old and not rewritten not that it wasn't written with a file system representation as primary view in the first place.
https://rwmj.wordpress.com/2010/02/18/why-the-windows-regist...
>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.
Anyway, file systems and databases are essentially similar, the point revolves more around the poor implementation of the Registry (whatever it is).
> Most of the actual technical issues you list have more to do with it being extended for the last 30 years in a backwards compatible way than anything to do with it being a hierarchical db instead of a filesystem.
My first line about it being a database was about point 7 in the same link:
> 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!
With "not a database" in bold.
Also, they would have been able to at least improve the on-disk format with a major version; I highly doubt that the registry itself is backwards-compatible anyway and there are probably very few programs that access it directly.
With how tightly the APIs for accessing the registry are coupled with the model and encodings of the registry, particularly the driver APIs for it, I don't think it would have been so easy to just swap out the back end without breaking something though (which Windows avoids like the plague) but maybe doable by someone more optimistic than me :). The real "rewrite" was the push for Universal Windows apps using the .NET platform which stores everything for the app in XML files and shadow directories instead of the registry. Of course that didn't take over quite like they hoped so they ended up back with using the registry they were trying to leave 10 years later.
A filesystem solves these issues specifically because it avoids reimplementation. As the registry has been extended as you say it approaches parity with filesystem functionality, but on a parallel track.
At a high level, avoiding multiple implementations of similar metaphors is ideal in terms of security. Reuse what you have.
"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!"
Noting "not a database" is bolded.
These are the kinds of categorizations that people can go nuts over. Rather than get too hung up on words I'd say that whatever this is, it can effectively be represented by a filesystem and therefore it should be as a matter of general architecture and security principle.
UDS are interfaced with via the same berkeley sockets api, not via the filesystem api. Have you ever written applications that use them?
What I was referring to were things like /dev/tcp/ and /dev/udp you'll find on Solaris (or emualated via bash on most systems) which are actual filesystem paths instead of handles in abstract namespace. A usage example of this comparable to binding to a socket with the BSD API to udp://localhost:2048 would be "echo "example" > /dev/udp/localhost/2048". The actual I/O is through the standard file/filesystem interface just like /dev/random. It's not the best for network sockets though so they tend to get a raw handle in every modern OS, even if it does mean rebuilding the wheel on some other things.
Network sockets are the canonical example of "not everything in Unix is a file". "Everything is a FD" is true but "everything is a handle" is true on any OS design, the uniqueness that things like ram and disks are just files under / did not hold true with networking.
And yes I have written plenty of apps with ipc sockets and network sockets and raw sockets and even underlying device access (for things like custom Ethernet packets). I'm in networking by profession.
Posix does not specify that network sockets should be accessed by file paths. It's possible to do so, but unspecified by the standard.
Sockets produced by socket(2) are regular old file descriptors, just as created by open(2) on a file path, or any other descriptor generating syscall like pipe(2) or epoll_create(2). There is no separate representation among any of these -- they are all just file descriptors. There are many, many ways to create descriptors and many aren't associated with a filesystem. There's no efficiency issue here, nor is there a divergence from a consistent pattern.
If you like, you can use fchmod(2) on a descriptor generated by socket(2) and change its permissions. You can track it by its inode. It doesn't matter that the descriptor is not linked to a filesystem, any more than for a similar descriptor created by pipe(2). They all have the same functionality and fit within the same consistent metaphor. When you run grep | grep, the pipe descriptor has permissions, mtime, ctime, atime and the rest. Everything just works.
It's trivial to write a filesystem to expose descriptors, in fact /proc does this already for all descriptor tables across all processes. There's no rebuilding of any wheel - the point of commonality is the "struct file" in linux/fs.h.
There's no such thing as a "raw handle" here, btw. That phrase has no meaning.
For where the main divergence in what we are each talking about though when I originally said:
> Similar case: posix specifies network sockets be accessed as files/filesystems (as most everything in posix is) but nobody actually used that representation because it's inefficient even though it's the standard and easily mappable to files/filesystems.
I was talking about literally exposing networking through the filesystem by mapping the construct to files and paths as that's what the author's registry tool actually does and what the author was proposing Windows should do in a rewrite - not whether or not sockets can be backed by the preexisting FD handle in an arbitrary namespace using custom socket functions to manage the socket efficiently. As a result I was trying to explain to you why BSD-type sockets don't use a literal filesystem mapping even if they have an FD and you were trying to explain to me how they were still backed by a FD even if it's not in the filesystem (i.e. describing the same API from opposite ends). I agree fully with your take it's a standard FD which has no performance concerns once created and can be treated as such but looking back I think I tried quite hard to point out I was talking about literal files/filesystems mapping not the FD handle so I'm not sure where the split came from... perhaps normally it"everything is a file" vs "everything is a FD" not a big distinction but this case just happened to be about a literal filesystem mapping not whether or not it would end up using a FD.
Also to note when I talk about "inefficient" I don't mean "slow to compute" (after all it ends up a FD once opened, as noted heavily at this point) it's the interface which becomes inefficient (which is what the registry article was dealing with). Even though you call it trivial as in "trivial to expose a mapping", which there is no argument is trivial BSD sockets offered much more straightforward and simple moldability around internet protocol network socket concepts than the filesystem approach by the author/TLI's approach which is a big reason BSD sockets won out. The "rebuilding of the wheel" are that the BSD socket API defines functions fit to purpose instead of molded around traditional file API naming and structure like TLI/XTI did.
In the section "It's not the best for network sockets though so they tend to get a raw handle" 'raw' was meant as another adjective to point out it was just a non-filesystem mapped reference (howso depends on the OS, in *nix still a FD in others not it doesn't really matter though it's just a ref) per the prior sentence not meant to be taken that 'raw handle' was a proper noun describing a different type of handle definition you'll find in the source code.
I appreciate the time, at the very least I'm sure I'll never make the error of conflating TLI with POSIX again and at the most I may have solidified some internals I don't get to think about every day!
There's nothing that has to be backwards compatible in registry internal storage format, they could just design new sane format and keep old API.
A better solution would be a simple database (like sqlite3) but then the immediate counter-argument is "okay, so we're done: it's already a simple database", because the registry hive is literally a file-backed database in the same vein as sqlite =)
You're right that a file per value would take a whole block on disk given the way some filesystems are currently implemented, but that's not an immutable feature of all filesystems - some Unix filesystems store small files in the inode. A real database is possible, but also the registry must be available very early in Windows boot (actually it's used by the bootloader, but also by the critical device database) so you'd want something that's at least easy to read with a smallish amount of code.
And, because almost every vendor thinks like that, median computers of today offer worse UX than their 90's equivalents.
Also the Windows Filesystem driver stack is not very efficient for accessing many small files. It's built for flexibility and security, not speed.
The importance of using a filesystem interface is reuse of the access control mechanisms and filesystem API. It would avoid the type of bug above, due to nesting a hierarchical permissioned structure inside a file.
Current machines aren't the ones as Windows 98 with 32MB of RAM requiring binary configs for the OS everywhere.
https://docs.microsoft.com/en-us/powershell/scripting/sample...
For example...
Set-Content hklm:\software\xyz\abc -value 1
...could create a DWORD value by default based on the type of the value argument, while adding '-DataType String' would enable creating a string value.
I can see no reason why in a filesystem-like representation of the Registry you cannot have a value.dwd (which is a DWORD), a value.bin (which is a BINary), value.esz, etc., or at least that is what I would use.