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

311–320 of 342 posts

Re: Why the Windows Registry sucks technically (2010)

#311

Post by BlueTemplar »

kjellsbells wrote: post #298
ahartmetz wrote: post #124

Earlier quoted context omitted.

Is that you, Dave Cutler? But more seriously, what do you want from an OS? Cleaner design? Plan 9 comes to mind. QNX is very elegant, too. Some microkernel thing? Fuchsia, but some say it's inelegant and overdesigned right off the bat. Minix has some nice properties but somehow nobody but Intel seems to use it. Also, QNX again (but as the name suggests it's similar to Unix)... Distributed computing? I don't know, see…

My concern isnt about Windows or Linux specifically but that something is lost when the garden only grows two plants. In, say, 1980 there were several unique OS streams, each with their own quirks: UNIX, Pick, VMS, etc. It seems strange that we are essentially trading on isotopes of OS thinking from about 2000 when Linux took the mantle of UNIX and Windows converged on the XP code. Is this it? Is producing an OS now…

We'll always have TempleOS ! /ducks (RIP)

Re: Why the Windows Registry sucks technically (2010)

#312

Post by int_19h »

nikau wrote: post #303
int_19h wrote: post #290

Earlier quoted context omitted.

It should be noted that putting configuration into files rather than registry has been the standing recommendation on Windows for a very long time now. For example, .NET 2.0 (2005) added a standard facility for application settings, and it was implemented on top of XML .config files.

Good to see MS practising what they preach on newly written applications: https://docs.microsoft.com/en-us/deployedge/configure-micros... > You can also use REGEDIT.exe on a target computer to view the registry settings that store group policy settings. These policy settings are located at this registry path: HKLM\SOFTWARE\Policies\Microsoft\Edge.

This is a group policy, not a setting. That makes a big difference in the right context - policies are meant for things that are typically centrally managed in enterprise environments, so the ability for the admin to remotely control every setting individually is important, and requires some kind of central system registry for OS tooling to work with.

Re: Why the Windows Registry sucks technically (2010)

#313

Post by MomoXenosaga »

palata wrote: post #308
kjellsbells wrote: post #298

Earlier quoted context omitted.

My concern isnt about Windows or Linux specifically but that something is lost when the garden only grows two plants. In, say, 1980 there were several unique OS streams, each with their own quirks: UNIX, Pick, VMS, etc. It seems strange that we are essentially trading on isotopes of OS thinking from about 2000 when Linux took the mantle of UNIX and Windows converged on the XP code. Is this it? Is producing an OS now…

Maybe it converged, just like other industries? Say, cars or planes have not fundamentally changed in decades. But would there be other designs that would make them so much better that it would be worth changing? That's not clear to me...

There's no money to be made in making an OS. Back when I was a child people were literally waiting outside stores for a new Windows. Windows 11 is given away for free.

Re: Why the Windows Registry sucks technically (2010)

#314

Post by zaptheimpaler »

jollybean wrote: post #188
pjmlp wrote: post #126

Earlier quoted context omitted.

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)

Exactly this. 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'.

Do you happen to know Linus' "first rule of kernel development"?

"If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs. How hard can this be to understand?" - from his famous rant [1]

So Linux prioritizes backwards compat as well. It would be insane for any project relied on by half the computing world not to. MS just throwing out their registry and rewriting it would probably break a million programs and possibly break literal billions of people's computers in some way. Its a universal problem - the more dependants any piece of code has, the harder it is to change.

[1] https://lkml.org/lkml/2012/12/23/75

Re: Why the Windows Registry sucks technically (2010)

#315

Post by jaclaz »

mananaysiempre wrote: post #67
veltas wrote: post #39

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…

>NTFS does the same, actually, except it can’t count that low, so you get 1K.

Not exactly, a $MFT record (on 512 bytes/sector media) is 1024 bytes, the most you can store in it (it slightly varies depending on the length of the filename and on the exact way the file is written) is 744 bytes max.

On 4K disks, the $MFT record is 4096 bytes and allows up to 3776 bytes max.

JFYI:

https://www.forensicfocus.com/forums/general/mft-resident-da...

Re: Why the Windows Registry sucks technically (2010)

#316

Post by the_why_of_y »

rwmj wrote: post #252
chasil wrote: post #129

Earlier quoted context omitted.

"The format is... endian-specific." Wasn't there a SPARC port of Windows? Did it run on any other big-endian machines? Were the MIPS and POWER ports little-endian? In any case, I can see why Microsoft paid SQLite for a custom set of features.

It's a very good question! There was also an Alpha port (both-endian and 64 bit). I've never seen a SPARC, POWER, MIPS or Alpha Windows registry so I don't know if hivex could decode them.

Larry Osterman said in 2005: A decision was made VERY long ago that Windows would not be ported to a big-endian processor.

https://web.archive.org/web/20190108142751/https://blogs.msd...

Re: Why the Windows Registry sucks technically (2010)

#317

Post by pjmlp »

zaptheimpaler wrote: post #314
jollybean wrote: post #188

Earlier quoted context omitted.

Exactly this. 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'.

Do you happen to know Linus' "first rule of kernel development"? "If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs. How hard can this be to understand?" - from his famous rant [1] So Linux prioritizes backwards compat as well. It would be insane for any project relied on by half the computing world not to. MS just throwing out their registry and rewriting…

Which is a reason no one has deep knowledge about all the ioctl variants out there on Linux, as new ones get introduced, sometimes to work around backwards compatibility guarantees.

Re: Why the Windows Registry sucks technically (2010)

#318

Post by viraptor »

jbverschoor wrote: post #243
hiptobecubic wrote: post #104

Earlier quoted context omitted.

.config/ and .local/ are the de facto /etc for users, but there is the set of XDG_ environment variables that are intended to fill that role.

Well, my git, ssh, caches of what not, almost everything is in my home directory directly. It's even worse than "My Documents"

Git uses XDG_CONFIG_HOME https://git-scm.com/docs/git-config#Files - putting the config directly in your home is just a choice.

Re: Why the Windows Registry sucks technically (2010)

#319

Post by qwezxcrty »

tenebrisalietum wrote: post #229

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…

About performance> try monitoring a non trivial Windows program with Procmon during it's start. I found the intensity of registry activity is quite extreme. Maybe many of those operations (many are by Windows itself) are not necessary, but in the current state, I feel happy that the registry is designed to be performant.

Re: Why the Windows Registry sucks technically (2010)

#320

Post by Jedd »

bzxcvbn wrote: post #276
Jedd wrote: post #68

Earlier quoted context omitted.

> 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... I'd suggest that last bit is not uttered in good faith. 20+ years ago you could install the Microsoft Office suite on the Microsoft OS du jour and you'd find…

If your argument relies on how things were in late 90s - early 00s, I don't know if it's really worth anything today.

That's probably a reasonable retort.

My response was to the claims that we aren't addressing the technical issues with the registry -- that is, if Microsoft was unable/unwilling to handle registry hygiene, what hope the rest of us? I have not run the same test on a modern OS / Office install and uninstall, but at the risk of exposing my biases, I'm not hugely optimistic.

Tangential aside - at the time I was working with a large Australian telco where we'd developed a SOE with robust roaming plus (effectively) package management for ~1500 desktop applications on a Microsoft Windows 3.x platform, all of which was largely kiboshed by the introduction of the registry.

Secondly, I feel I've already addressed your 'at least it's not as bad as the /etc mess' by pointing out that /etc is not a mess on some, perhaps all, GNU/Linux distros with a good package management system.

To paraphrase - if your argument relies on how slackware handled /etc in the late 90's, I don't know if that's worth anything today.

Post reply on HN