Ok fine, I'll bite. #1 is pretty terrible. It's like complaining that a bicycle is a half-baked car. #2 (and part of #1) is also irrelevant. "The format is ba

Ok fine, I'll bite. #1 is pretty terrible. It's like complaining that a bicycle is a half-baked car. #2 (and part of #1) is also irrelevant. "The format is badly constructed, fragile, endian-specific, underspecified and slow." So what? The file format is not the business of anyone actually using the registry, and nobody was making claims about the file format anyway. What you have is the APIs and the guarantees those provide you. Complaining about the file format when you will never even be accessing the file contents is like complaining that the remote engineer you hired has a rip in their T-shirt. You just care because you're breaking into the house from Linux and then getting upset that it doesn't look the way you like. #3 is again pretty terrible. "The upshot of this is you can easily hide stuff in the Registry binary which is completely invisible to Windows." OK, so if you don't like that then don't do that. I'm sorry (?) the Windows registry was not designed with making life easy for Kali Linux hackers. #4 is at least on the same planet as something I could consider as maybe vaguely interesting. But it's not like your life is any different on a filesystem. Even .txt files could be ASCII, UTF-8 with BOM, UTF-32, or some weird code page. If you hate that fact of life, you need to direct your hate toward the person who made the file whose contents you're trying to read. #5 is vaguely interesting but again, practically irrelevant for people writing applications (unless you're writing a registry editor I guess). It's more relevant for end-users dealing with .reg files, and the interchange format for them is pretty obvious: follow whatever regedit does. If you find that file format poorly documented... big deal. Just export what you want and look at how it gets encoded, and you'll remember it thereafter. "The registry sucks" does not follow from "I have to spend 5 minutes figuring out how to write this text file for something irrelevant to >99% of use cases because it's not well-documented". If that's your standard then the Linux kernel would be an absolute dumpster fire with how lacking it is in the documentation department. #6 finally something I can at least comprehend. OK, so evolution & backward compatibility introduces some warts, just like it does on Linux or any other OS. Documentation of internals could probably be better... just like with Linux or any other OS. Though "non-standardized" is a strange complaint for Windows, given there aren't 1000 different companies releasing their own Windows distributions like there are with Linux, for whom having a standard would actually make sense. And it's not like you don't have %AppData% at your disposal if you really like files. #7 is again like #1. The registry is intended for low-latency, low-throughput access to small bits of data. The filesystem is intended for high-latency, high-throughput access to large & growing data. You don't complain that your knife can't cut down trees; you use a chainsaw instead. You need to use the right tool for the job. "It should be a database!" ...sure, so should ext4. #8 is almost onto something here, but misses it and veers 90 degrees in the wrong direction. The argument you could make is "it's difficult to manage registry ACLs separately from the filesystem", which I could understand; Windows security is complicated, which is not great for security. You could flesh this out into a good argument here, though it wouldn't really be specific to the registry. But the grumbling (yet again) about the format of the hive file because it's not "hackable" enough for Linux users' taste really is... I don't even know what word to use for this, but a good argument it does not make. Unless your audience is Windows hackers using Kali Linux, I guess. #9 Huh? That's not even new; both "Application Data" and "Local Settings\Application Data" were a thing before Vista. Vista just redid the folder structure for {reasons}. The new thing it added (I think?) was e.g. LocalLow, which hardly anyone has a reason to use. The registry is neither obsolete nor a mess just because you claim it so. It took me > 1 hour to write this, so I hope it's useful.