Live data from Hacker News

Why the Windows Registry sucks technically (2010)

rwmj.wordpress.com

271–280 of 342 posts

Re: Why the Windows Registry sucks technically (2010)

#271
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…

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…

I'm not saying the UNIX philosophy is the "best" way, I'm just stating why it's valuable.

Of course most people don't care about those things, but as a developer, the main issue I see with Windows and macOS, is that they build specialized interfaces that lock you into certain ways of doing things, which may be convenient, but are difficult to migrate away from, and a pain to automate and reproduce.

I really value that the UNIX philosophy is geared more towards building simple tools that are designed to be combined with other simple tools to solve a more complex problem, and that it doesn't try to lock you into using any particular tool to solve a problem.

So no, I may not provide binaries for Windows & Mac for personal projects, but I'm not going to be openly hostile towards people who want to build things from source or contribute fixes for Windows & macOS.

Re: Why the Windows Registry sucks technically (2010)

#272

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

yeah, such a classical Microsoft move

it was a very common approach at the time.

Re: Why the Windows Registry sucks technically (2010)

#273

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…

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

non-microsoft programs were not intended to use it when it was designed. the performance considerations are for windows itself.

Microsoft's guidance has always been for third party applications to manage their own configuration in whatever way they choose, so long as it isn't the registry.

developers ignore that, use the registry, and blame Microsoft for keeping the registry around even though Microsoft promises to do everything they can to keep things backwards compatible.

Re: Why the Windows Registry sucks technically (2010)

#274

It is easy to be critical of Microsoft and many of their decisions until you reflect on the reality that they have provided the software that has been running billions of computers world-wide for almost four decades. And they have done this with an astounding level of software and hardware compatibility across time, devices and technologies. This is critical to understand before pointing at anything MS and being crit…

> And then imagine having to stay as true as possible to that rule for 40 years. And then imagine that most of your original decisions were poor ones, you won your position by virtue of being an abusive monopoly, and as a result, the majority of the desktop world has been needlessly suffering under the burden of your poor technical decisions for 40 years.

Microsoft's secret is, and always has been, incompetent competition. If you invent a time machine, don't kill Bill when you go back. Build something that's genuinely better for both users and developers.

Re: Why the Windows Registry sucks technically (2010)

#275

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…

> I don't understand all the talk about performance - programs should be reading config once on start up and that's it. non-microsoft programs were not intended to use it when it was designed. the performance considerations are for windows itself. Microsoft's guidance has always been for third party applications to manage their own configuration in whatever way they choose, so long as it isn't the registry. developer…

non-microsoft programs were not intended to use it when it was designed. the performance considerations are for windows itself.

That's not what I remember. Someone at Microsoft had a personal jihad against application-specific .INI files scattered all over the place, and came up with the registry as a centralized solution.

I still use .INI files myself, although Microsoft did successfully manage to get me to stop putting them in the executable directory where they belong. :-P

Re: Why the Windows Registry sucks technically (2010)

#276
post #68
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…

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

Re: Why the Windows Registry sucks technically (2010)

#277

Earlier quoted context omitted.

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…

Windows these days works extremely well with just taking out the hard drive and placing it into a different computer, even across different processor brands completely different hardware etc.

I personally do this all the time. At most you get an extra restart the first time the drive is in a new set of hardware and after that you're good to go.

My main Windows install is probably 8 years old at this point, it's gone between multiple motherboards.

The biggest annoyance is a few pieces of software that tie activation to the motherboard.

If you want to make it even more portable you can install Windows to a vmdk.

And if you want to get a special complicated, you can have that vmdk act as essentially a secondary variant of your main operating system complete with symlinking most of the files and application info, to both save space and so you have most of the same state across both os's, but still can play around and easily roll back any changes.

Re: Why the Windows Registry sucks technically (2010)

#278
post #174

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.

I'd be more inclined to believe in just a Linux instance running Office. 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.

Apple supported OS 9 running 'containerized' atop what was essentially Openstep for a few years.

Worst-case I could see a Windows GUI running atop a heavily-symlinked Debian, and all Office things running Web-based. Everything else that can't run native could be in obscured VMs. At some point, the NT kernel isn't going to cut it.

Re: Why the Windows Registry sucks technically (2010)

#279
The alternatives sorta fail the KISS principal since in general the registry grew out of the win3.x .ini config API's which are sorta the equivalent of the files in /etc, but the format was more regular.

Given its mostly read only data, I suspect no one thought that it was going to grow into the huge monstrosity its become, yet at the same time, unless your looking for a full ACID database, and your looking for a lightweight solution it would probably sit a lot closer to the registry API and format than it would something like sqlite.

Someone at some point should have probably said enough, and duplicated some effort and kept the registry for OS/etc settings while splitting off the people who want something closer to an ACID database into an actual database. Of course that has happened a couple times now (aka MDB?).

Re: Why the Windows Registry sucks technically (2010)

#280
post #221

Earlier quoted context omitted.

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!

Was there anything specific about Bell Labs or working for the Bell system that influenced the design of UNIX and the userland tools? Did the needs of the Bell system influence any of this work, or was it pure computer science research (and the needs of the computer science research community) that influenced these designs? If awk were "designed for someone" who was it designed for? Did anyone who worked on UNIX or the computing stuff at Bell labs care about building things for telephone network operations or was it pure research and technology development for the art of it?

--

Good question! Many books have been written about why Bell Labs was so successful in creating research innovations that changed the world.

Bell Labs was interested in building operating systems even before the 1950s for use in AT&T's operations support systems for the global telephone network. (You might look at the Wikipedia article on BESYS.) In 1964 Bell Labs joined with MIT and General Electric to create an advanced operating system called the Multics project. (The article Unix and Multics at https://multicians.org/unix.html provides a lot of useful background. Also see Dennis Ritchie's article, The Evolution of the Unix Time-sharing System, which is a must read on the early development of Unix.)

In the 1960s Ken Thompson at the Computing Sciences Research Center at Bell Labs, Murray Hill, NJ worked on the Multics project. When Bell Labs pulled out of the Multics project in 1969, Ken Thompson on his own decided to build a much simpler operating system which became known as Unix. Dennis Ritchie, also in the CSRC at Bell Labs, joined Ken in creating Unix. Dennis invented the C programming language for this effort. Subsequently, many people in the CSRC and elsewhere contributed to the development of Unix. Doug McIroy (Ken Thompson's boss and the inventor of coroutines and pipes) deserves a lot of credit for shepherding the development of Unix.

The reason Unix and C became so successful is that they were designed by individuals with very good technical taste and not by committees. The Bell Labs research culture also let individuals have great discretion in determining what direction their research should take and one of the important functions of management was to provide adequate resources to make research projects successful and ultimately beneficial to the development of the global telecommunications infrastructure. Another motivating force for Bell Labs research was to create a patent portfolio for the company that could be used to get access to patents of other companies by cross-licensing.

What I found immensely gratifying by being involved with Unix was what Don Knuth had once told me. He said, the best theory is motivated by practice and the best practice by theory.

As for the motivation behind awk, I recommend looking at https://www2.computerworld.com.au/article/216844/a-z_program...

Post reply on HN