Windows 95 wasn't multi-user and was from a time when the only software most people would install was some they bought from a company you trust. I hazard a guess that with NT4 and Windows 2000, the user hive was unlikely to be able to crash your system - sure something probably could, but it was at that point separate between what a user could do and what an admin could do. At that point, giving an installer root access to affect the system areas and then complaining that it could screw up a computer, would happen on any OS from any company. If your argument is really that "it was a free for all initially therefore I discount anything they learned or changed since" - that isn't very convincing.
> But a problem in program.conf would sabotage the program, not the entire system. Whereas a bad registry can stop you from booting. That is the main problem.
A bad user hive stored on a network drive, can stop a terminal server from booting? Can it? That's the comparison with /home/.program/program.conf that you're replying to.
> A real unix equivalent could maybe be a problem with something in /etc, but that stuff is supposed to be 1) set to basic defaults that will work in any circumstance
Like a kind of "safe mode" that can boot after something has screwed up the registry?
> That's why developers end up managing text files: because they work everywhere, in 1995 as in 2019; whereas APIs come and go.
Yeah, I've never had to fix character encoding issues in text files, or line ending, or newline at end of file, or escaping or quoting issues in text files, because they're all the same and never cause any problems. Microsoft APIs from years ago still work.
Indeed, at that was a major mistake. Multi-user systems had existed for 20 years, Windows 95 was a huge step back.
> I hazard a guess that with NT4 and Windows 2000, the user hive was unlikely to be able to crash your system
... you wish.
> A bad user hive stored on a network drive, can stop a terminal server from booting?
Maybe, I honestly have no idea - I've only seen it happening locally. I wouldn't put anything past registry corruption anyway.
> Like a kind of "safe mode" that can boot after something has screwed up the registry?
Access to Safe mode requires hardware action at boot. The worst you can get from a userland program in unix failing on logon is that you have to log on via shell.
> Yeah, I've never had to fix character encoding issues in text files
The difference is that you can fix all that yourself, with a shell and an editor, whereas if Windows says the registry is borked, the registry is borked and you have no recourse.
Indeed, at that was a major mistake. Multi-user systems had existed for 20 years, Windows 95 was a huge step back.
Single-user systems had existed for longer. They were dominant at the time especially on small systems - many variants of DOS, Windows 3.1, OS/2 up to version 3, Apple MacOS up to version 8, Amiga, Acorn, Atari, every console, every 8-bit micro, Symbolics Genera[1], BeOS pretended to be single-user. The days of a central computer with tons of connected terminals requiring multi-user auditing, separation, and billing - were fading. Individual computers were becoming cheaper, the internet hadn't risen. Looking back with hindsight of how things turned out, and saying "huge step back" when it was not a step back at the time, it was a step forward from Win 3.1 in many ways and a step sideways in that way, seems weird.
We still have not-multi-user systems now, for embedded devices and mobiles and similar. If it wasn't for network effects, it ought to be possible to make a single-user OS which was simpler and therefore faster and cheaper, and I bet it would be good enough for much of the computing done on the planet today - the amount of personal computers where multiple people need to logon, compared to the amount where you just want random people not to be able to poke at it without permission. Although totally not worth doing these days.
You started this bit by saying "once you give third parties control of the stability of your system, you lose". That happens if you give root access to anyone, on any platform. That happens in Windows 95, but the registry had system/user separation since Windows 2000. So that's 5 years without, vs 20 years with.
Yes I wish it was without problems, and that it had some more standard offline edit ability, but I don't think "userland can crash the system" was a design plan for the registry, so I don't judge it as bad design because of that.
> But a problem in program.conf would sabotage the program, not the entire system. Whereas a bad registry can stop you from booting. That is the main problem.
A bad user hive stored on a network drive, can stop a terminal server from booting? Can it? That's the comparison with /home/.program/program.conf that you're replying to.
> A real unix equivalent could maybe be a problem with something in /etc, but that stuff is supposed to be 1) set to basic defaults that will work in any circumstance
Like a kind of "safe mode" that can boot after something has screwed up the registry?
> That's why developers end up managing text files: because they work everywhere, in 1995 as in 2019; whereas APIs come and go.
Yeah, I've never had to fix character encoding issues in text files, or line ending, or newline at end of file, or escaping or quoting issues in text files, because they're all the same and never cause any problems. Microsoft APIs from years ago still work.