Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why the Windows Registry sucks technically (2010)

rwmj.wordpress.com

Post reply on HN
Print view View original

201–210 of 342 posts

Re: Why the Windows Registry sucks technically (2010)

#201

Post by pie_flavor »

mhink wrote: post #185
guhidalg wrote: post #102

Earlier quoted context omitted.

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…

> 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. 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…

The registry does not impact those users' experience. Needing to learn how to use a shell, does.

Re: Why the Windows Registry sucks technically (2010)

#202

Post by momentoftop »

behnamoh wrote: post #163
f1refly wrote: post #88

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.

I think it's all too easy to say they should have just used an existing language. The most obvious feature of the nix language is that it's lazy, because they want their enormous collection of configuration dictionaries computed on demand. There are no mainstream languages that are lazy.

Well, there's Haskell, and I expect any Haskell programmer to be able to pick up Nix very quickly.

Guix has gone with a strict language, Scheme, but I understand they have their own monadic DSL to cope with the peculiarities of following the Nix model. So again, not something that a mainstream language can do well, and even as a Schemer, you're going to have to learn their macro language.

Re: Why the Windows Registry sucks technically (2010)

#203

Post by layer8 »

JonathonW wrote: post #166
layer8 wrote: post #138

Earlier quoted context omitted.

You can’t look at HKEY_CLASSES_ROOT and claim with a straight face it’s not complex, and it’s a central piece to how a lot of things work in Windows.

HKCR has a lot of entries, but the data underneath those entries isn't particularly complex. Its only really big misstep (apart from the fundamental issues with the registry in general) is that file associations and COM registrations are all intermingled in the same namespace. But those can be and are interconnected (see how the Office file types handle their registrations, for example), so it's kind of understandabl…

The semantics of those entries and their possible subkeys is exceedingly complex. It started out reasonably simple, but features upon features were added with each Windows release, in addition to the application-specific behaviors.

Re: Why the Windows Registry sucks technically (2010)

#204

Post by a-dub »

woodruffw wrote: post #194
a-dub wrote: post #179

i think the windows registry probably sucks because windows was primarily built to enable developers and end users to use microcomputers to make money (where messes are acceptable as long as it makes money) and unix differs in that it was built to enable telephony engineers to operate a telephone network reliably and efficiently. so if you're an engineer or scientist or care about operations, you like unix style syst…

> unix differs in that it was built to enable telephony engineers to operate a telephone network reliably and efficiently. This is a corporate revision of Unix's history: it was originally created to run a video game[1]. Later, when Bell Labs gave that team some more resources (in the form of a PDP-11), the first "business" applications they wrote for it were primarily for typesetting and text editing. Telephony was…

perhaps the kernel, but i suspect that much of the userland (which is a lot of what i reference here when i say "unix"- all the command line utilities, shells, the C programming language) was influenced by the needs of both the research community and the technical operation of the telephone network itself.

Re: Why the Windows Registry sucks technically (2010)

#205

Post by tomcam »

ElectricalUnion wrote: post #99
mikepurvis wrote: post #75

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}

I don't mind dot files or dot folders, but I'm very open to better ideas. My app works on Mac, Linux, and Windows though. Any thoughts?

Re: Why the Windows Registry sucks technically (2010)

#206

Post by NonNefarious »

Someone1234 wrote: post #9

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…

key/value pairs

Re: Why the Windows Registry sucks technically (2010)

#207

Post by pie_flavor »

rwmj wrote: post #92
magicalhippo wrote: post #78

Earlier quoted context omitted.

Based on the documentation[1], it seems clear that strings are stored in Unicode (which should be UTF-16LE). If the data has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, and the ANSI version of this function is used (either by explicitly calling RegGetValueA or by not defining UNICODE before including the Windows.h file), this function converts the stored Unicode string to an ANSI string before copying it to the b…

The first thing to know about Microsoft documentation is it's almost always wrong.

This is categorically incorrect. The documentation for the function is entirely accurate. What is true is that the regedit program is more than a featureless wrapper around the API functions (unlike the first thing to know about Linux desktop software). The heuristic is performed for the user who probably doesn't know what they want; the straight exactly-as-you-asked-for-it conversion is performed for the programmer who does. (And it's only a heuristic for values; the encoding for keys is assumed from the file like TFA says, but which one it is is stored in a flag bit.)

Re: Why the Windows Registry sucks technically (2010)

#208

Post by pie_flavor »

silvestrov wrote: post #83
Someone1234 wrote: post #9

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…

If I was to reimplement it, I would not let any app read the DB directly. Instead I would make an HTTP like interface where you talk to a service that provides the get/set functionality and which always use a text format like an extended JSON with native support for date, int32, etc. This also enabled much easier and better backwards compability as you can specify app-version in the requests, so a version 5 server ca…

The article's complaints about the format being undocumented are ill-founded, because Microsoft repeatedly tells developers not to read the registry directly, and call the exquisitely documented functions instead. The applications that didn't listen to Microsoft and depended on particular features are most of why it hasn't updated to modern standards in the first place.

Re: Why the Windows Registry sucks technically (2010)

#209

Post by woodruffw »

a-dub wrote: post #204
woodruffw wrote: post #194

Earlier quoted context omitted.

> unix differs in that it was built to enable telephony engineers to operate a telephone network reliably and efficiently. This is a corporate revision of Unix's history: it was originally created to run a video game[1]. Later, when Bell Labs gave that team some more resources (in the form of a PDP-11), the first "business" applications they wrote for it were primarily for typesetting and text editing. Telephony was…

perhaps the kernel, but i suspect that much of the userland (which is a lot of what i reference here when i say "unix"- all the command line utilities, shells, the C programming language) was influenced by the needs of both the research community and the technical operation of the telephone network itself.

I'm more than happy to be corrected about this, but my understanding is that the groups at Bell Labs that created and matured Unix were not closely tied into the telephony groups, if at all.

The lack of interest in telephony use cases is evidenced by early releases and "workbench" distributions for Unix: PWB/Unix[1] focused on providing a development environment for programmers, and WWB[2] was aimed at technical editors and writers.

(The functionality of the basic Unix tools reflects this lineage: there a lot of tools for munging text, and very few tools for interacting with peripherals and hardware that isn't a teletype or line printer.)

[1]: https://en.wikipedia.org/wiki/PWB/UNIX

[2]: https://en.wikipedia.org/wiki/Writer%27s_Workbench

Re: Why the Windows Registry sucks technically (2010)

#210

Post by cma »

pie_flavor wrote: post #199
daxvena wrote: post #63

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…

General Linux tools built for text, in a world where everything is plain text and the shell doesn't know how to navigate anything other than a file system. In PowerShell you can cd into HKEY_LOCAL_MACHINE as easily as any drive, and Select-String is perfectly capable of searching registry keys. The baseline is only text and files on systems that don't have anything better to offer.

Isnt there FuseFS for that? It can show the gconf registry as a file tree, allowing you to use tools like recursive diff etc. https://metacpan.org/release/LSIM/GConf-FS-0.01

Something flexible like FuseFS is sorely missing on windows, the stuff google drive had to do creating a new letter drive is pretty gnarly.

Post reply on HN