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

221–230 of 342 posts

Re: Why the Windows Registry sucks technically (2010)

#221

Post by a-dub »

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

Earlier quoted context omitted.

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

good question. i sent al aho an e-mail. hopefully he'll reply with some interesting history. watch this space!

Re: Why the Windows Registry sucks technically (2010)

#222

Post by LukeShu »

jeroenhd wrote: post #38
bzxcvbn wrote: post #20

> This is a far cry from /etc/progname.conf in Linux. Some of these arguments are not really in good faith. First, this isn't a technical issue with the registry, but with how it's been used over the years and never "refactored" - a distinct issue. Second, I dare you to run "ls /etc" and claim it's not a mess... Besides, most of the post is how anyone with a text editor and admin rights can bork/hack the machine. As…

I love editing files in /etc ending in conf! Some are pseudo-INI (OpenSSL), some are pseudo-XML (Apache2 and friends), some are some kind of unholy amalgamation between C and YAML (nginx, dhcp daemons), others are some kind of TOML derivative (systemd, NetworkManager) and there's also some diet JSON in there! Netplan uses YAML, of course, though JSON will probably also parse. It's always a fun adventure to reverse en…

> some kind of TOML derivative (systemd, NetworkManager)

A bit off-topic, but it's funny to me that you identified these as a "TOML derivative", when both of the mentioned pieces of software predate TOML. Systemd uses D-Bus's flavor of INI. IDK if NetworkManager uses exactly that same flavor or not, but it's pretty similar at least.

Re: Why the Windows Registry sucks technically (2010)

#223

Post by LexGray »

kalleboo wrote: post #103
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…

I'm a big fan of the macOS method where there's an OS API to manipulate the user defaults (as its called) but they are actually just stored as files in a standardized format (usually XML). You get the pros of the standardization and the pros of user manipulation (like easily deleting the corrupted settings of some app by removing one or two files)

At least that used to be the macOS method. Once Apple moved most of their apps to the cloud there are constantly open databases pushing settings updates from device to device. Things often start breaking these days if you try to fix things through direct file manipulation.

With luck you might be able to find the correct terminal commands to disable services and fingers crossed they don't automatically restart themselves before you are done editing.

Re: Why the Windows Registry sucks technically (2010)

#224

Post by ElectricalUnion »

throw0101a wrote: post #147
5e92cb50239222b wrote: post #140

Earlier quoted context omitted.

It's a great thing about etc. If your application `foobar` wants to write something to /etc and doesn't have root privileges (which it probably shouldn't), create a subdirectory /etc/foobar with owner `foobar:foober`, and write there all you want. Many applications do that and it works fine.

Strictly speaking /etc should be relatively static, and dynamic data should go into /var, so you (or the package installation) would create /var/lib/foobar with proper ownership.

> Strictly speaking /etc should be relatively static

I really wish that was true but nasty stuff like wpa_supplicant/, resolv.conf (now usually a systemd-resolved managed symlink), NetworkManager/ and X11/ lives there, very mutable and often constantly changing under the hood.

Re: Why the Windows Registry sucks technically (2010)

#225

Post by mananaysiempre »

Tempest1981 wrote: post #193
mananaysiempre wrote: post #67

Earlier quoted context omitted.

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…

I'm trying to remember Win95 on FAT32 (or exFAT?)... on a large hard disk, wasn't the smallest file size 32KB or 64KB? Different times...

I could swear this was the cluster size for FAT32 on a 2G drive, but apparently not[1], this is the cluster size for FAT16 on 2G. FAT is just utterly dumb in how it does space allocation: it doesn’t even have a bitmap, it’s just a gigantic dense array of linked list nodes (the eponymous file allocation table). Perfectly fine for a 360K floppy on a 32K machine, predictably painful for a 2G hard drive on a 32M machine. Add in narrow allocation unit (“cluster”) numbers, and you end up with huge allocation units.

As far as I can see, ext2/3 instead use a free bitmap and a tree-style “indirect block” setup that is recognizably similar to (though greatly extended from) V1 UNIX (1971) [2], predating even the original FAT8 (1977). Ext4 can do extent [that is, (start, end) pair] allocation instead, and XFS, ZFS, Btrfs, etc. are built around it. Thus they can and actually do manage disk space in smaller bits.

[1] https://support.microsoft.com/topic/default-cluster-size-for...

[2] http://squoze.net/UNIX/v1man/man5/fs or https://www.bell-labs.com/usr/dmr/www/pdfs/man51.pdf

Re: Why the Windows Registry sucks technically (2010)

#226

Post by yndoendo »

pie_flavor wrote: post #201
mhink wrote: post #185

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

I would disagree that it does impact users' experience because when the registry gets corrupt you have to start by installing Windows from scratch. Nothing like Windows 10 update disabling registry backups to save space on low capacity storage and finding out after the fact when attempting to recover Windows 10.

Secondly with device drivers being tied to the registry there is not a simple system upgrade of taking out the hard drive and placing it into a new computer.

Just not everyday occurrences for most but still exist.

Re: Why the Windows Registry sucks technically (2010)

#227

Post by swinglock »

greenthrow wrote: post #6

I don't feel like this article is good enough to be worth resharing 12 years later. It missed some of the key reasons why the Registry is bad and other criticisms ("We have to write exactly the bytes Windows expects." yeah of course you do. It's only meant to be changed using APIs.) are not very well thought out. The criticism that the Registry is a janky filesystem in a single file is dismissed because you can do th…

Much like SQLite or what have you. What specifically is problematic about that, or what would be better?

Re: Why the Windows Registry sucks technically (2010)

#228

Post by ComputerGuru »

fortran77 wrote: post #58

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 been around since Windows NT. Whether or not Microsoft uses it for their own (in-box or out-of-box) products is a different question.

Re: Why the Windows Registry sucks technically (2010)

#229

Post by tenebrisalietum »

Text files are better because I can use any text editor to update or change them, and leave comments/notes in the file.

I don't understand all the talk about performance - programs should be reading config once on start up and that's it.

Registry keys I guess serve the programmer better by providing types and paths, but user space libraries can be used and since it's not kernel-level string handling code, a lot safer. Then again for I know ntdll.dll or kernel32.dll or whatever does actually run its registry API functions in userspace.

Also, since the registry doesn't provide an opportunity for self-documentation, updating configuration using a common, trustable tool (regedit) is generally something you do only as a last resort when armed with knowledge or documentation that you'd have to hunt for elsewhere. Realistically you'll have to use control panel applets or settings dialogs in programs themselves.

Re: Why the Windows Registry sucks technically (2010)

#230

Post by sumtechguy »

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…

https://docs.microsoft.com/en-us/windows/win32/sysinfo/regis...

Registry settings already have ACL items applied. You can see this behavior if you log in as a non admin user then try to view another users registry settings.

https://docs.microsoft.com/en-us/windows/win32/sysinfo/regis... The thing is pretty free form with a choice of some very basic data types dword/qword and strings ascii/unicode/lists of strings.

Adding a wrapper around the existing call to go towards a json schema registry could be a helpful thing.

Post reply on HN