181–190 of 342 posts
Plus, it's inscrutable and malware developers seem to know it better than legit developers do.
There's no reason for a legit developer to know the registry format, as you're supposed to interact with it using syscalls. Most of this article takes place in a parallel universe where Microsoft forgot to provide syscalls to access the registry, and you have to open its file store directly or something.
A point being overlooked by article and commenters: the records in the registry probably use in the order of 10-100 bytes each, while every actual file takes up at least around 1024 (EDIT: maybe more like 4096?) bytes. Putting tiny 'files' into a special format is a no-brainer on the older computers that existed when the Registry was first created. I am assuming this was one of the motivations to create the Registry…
On ext4, a file of 160 bytes or less (and no xattrs) can be stored inline in the inode[1], so the whole thing takes up 256 bytes (plus 8 + [length of filename] for the directory entry). I don’t think any Unix filesystem did that in 1989, but the problem is not unsolvable, especially given that you are hardly going to use a configuration file to store a single value. NTFS does the same, actually, except it can’t count…
It can if you enable an option that is not widely used, IIRC.
Earlier quoted context omitted.
> The UNIX way is undeniably more flexible since it isn't a virtual filesystem, it is just a filesystem. Unix simply doesn't have a "way" in that regard, other than a loose convention to put text files in "/etc". Every application comes up with its own format. Parsing that file is application-specific. Updating a value in a text file means re-writing the whole file again. It is a technically-inferior approach that ha…
I would actually be better if most of the data that applications store in the registry would instead live in simple text files in the AppData directory (which shouldn't be hidden by default). The registry should be restricted to Windows configuration data (like file types and their associated programs), and information that needs to be shared between installed applications.
Earlier quoted context omitted.
The people at nixos and guix are doing it differently. No longer is the configurarion just state in files, scattered who knows where that cannot be understood fully by anyone. Insteady everything is defined centrally and then neatly versioned and managed by the system. If you think the unix way of throwing files in a directory sucks, check them out!
Unfortunately, Nix's documentation sucks. Plus, there's a steep learning curve to the Nix programming language. I don't understand why they couldn't just use a language instead of inventing one that is only usable within the Nix system. Overall, really cool idea (dropped my jaw when I first saw it in action), but poorly implemented.
What's rather messy about Nix is nixpkgs with its helper functions all over the place alongside pretty shallow / non-existent documentation (which is unrelated to the language). Thankfully they've started to work on that recently: https://discourse.nixos.org/t/documentation-team-flattening-...
Earlier quoted context omitted.
I get where you're coming from, but I think the biggest pro for the "UNIX way" is that text on a filesystem extremely accessible. You don't need a specialized tool to read & modify configuration, you just need a text editor. And while there's no standard for how the data is structured, it's usually pretty easy to figure it out from context. I think it's also really easy to underestimate all the tooling built around t…
Windows and macOS dominate because 99.9% of users do not care about the difference between registries, file systems, text or binary tools, UNIX-like, POSIX, etc… none of these things matter to them! They just want to use a computer and get on with their life. If you lament this as a programmer, build applications that only work on your OS of choice, make them so good or take a dependency on a feature not available wi…
The flip side of this argument is that the experience of using computers for that 99.9% of users sucks.
As software engineers, it's almost our responsibility to argue in favor of better platforms, because every day not spent fighting the platform is a day we could be building better experiences for our users. (Not to mention, every day the platform doesn't inadvertently mess up the user experience is a day of smaller support costs.)
Earlier quoted context omitted.
The biggest issue with etc is that it's owned by root and therefore read only from the application's point of view. So, a great fit for sysadmin-managed configuration, not so great for applications that are GUI-configurable. You end up with a tiered approach of defaults in lib, and cascaded overrides in etc and var.
Most Linux GUI apps either litter your home folder with dotfiles, dotfolders (both disgusting) or they follow XDG Base Directory specifications and place configurations in ${XDG_CONFIG_HOME:-${HOME}/.config}
>Hello Microsoft programmers, a memory dump is not a file format Wait until you see the Office formats without the extra x in the extension.
That was a deliberate attempt to make it impossible for competitors to read and write their format wasn’t it?
When all the world runs one architecture, why wouldn't you do that?
I really appreciate when people use technical facts to criticize something, like with this. It is a well written take-down of the implementation of the Windows Registry as of both today and 2010. I suspect if the concept of the registry was created today it would look more like a database (e.g. Sqlite), although organizing it like a virtual FileSystem does have a certain appeal, and unfortunately I don't know of a da…
What UNIX way? The religious text files scattered everywhere on the FOSS clones? The adoption of registry ideas by GNOME on gconf? The configuration databases used by HP-UX and Aix? The plists used by NeXTSTEP and macOS? The settings per app used on Android (technically UNIX based at its Linux kernel)
Unix is a bit of a mess, at least that's understandable because it's 'open'.
MS registry is a bit nutty, it should be refactored in some simple, clean way, which is apparently extremely difficult to do for big companies, especially those that consider 'backwards compatibility' to be 'everything'.
Windows 10 and 11 have moved away from the registry for applications. It's in C:\Users\ \AppData\Local\ for per-user information I haven't had to go into the registry on Windows 10 or 11 except for enabling beta/early access features.
That's a new alternative to the registry, and some prominent programmers like Raymond Chen have promoted using it, but it's still up to app developers which they want to use. I doubt that the registry is going away any time soon.
With zero solid evidence to support my belief, I am certain that somewhere in Redmond there is a Windows instance, running "Office," atop a Linux kernel.
The NT kernel is so incredibly different from the Linux kernel, and the Windows shell takes such extensive advantage of it, that I can't even begin to imagine the compatibility layer required.