Live data from Hacker News

How did the Win 95 user interface code get brought to the Windows NT code base?

devblogs.microsoft.com

71–80 of 114 posts

Re: How did the Win 95 user interface code get brought to the Windows NT code base?

#71
post #60

Windows is like real life archeology. You can dig up the UI of ancient generations of humans before you underneath the modern facade.

Vernor Vinge's A Deepness in the Sky depicts a human society thousands of years in the future, in which pretty much all software has already been written; it's just a matter of finding it. So programmer-archaeologists search archives and run code on emulators in emulators in emulators as far back as needed. https://garethrees.org/2013/06/12/archaeology/ > (Heck, recently I migrated a VM to its third hypervisor. It be…

ironically, that link 404s...

Re: How did the Win 95 user interface code get brought to the Windows NT code base?

#72
post #60

Earlier quoted context omitted.

Vernor Vinge's A Deepness in the Sky depicts a human society thousands of years in the future, in which pretty much all software has already been written; it's just a matter of finding it. So programmer-archaeologists search archives and run code on emulators in emulators in emulators as far back as needed. https://garethrees.org/2013/06/12/archaeology/ > (Heck, recently I migrated a VM to its third hypervisor. It be…

ironically, that link 404s...

Hah, so it is! Sorry about that. https://web.archive.org/web/20231114211656/http://www.gareth...>

Re: How did the Win 95 user interface code get brought to the Windows NT code base?

#73
post #36
post #32

Earlier quoted context omitted.

In Windows 11 you're only 3 clicks away from a Windows 3.1 dialog box: ODBC Data Source Administrator (64-bit) Configure > untick "Use Current Directory", Select Directory

Well, it's not that the latest Office is that much different in this sense... just open Word, add a tab stop, double-click on it and you get a dialog box that probably was almost identical in Word 6 on Windows 3.1. Not that it looks bad or anything, it's perfectly appropriate IMHO. I still dream of getting back menus in Office, now some functions are so hidden that if you don't use them often enough you always lose a…

Clicking the "100%" next to the zoom slider gets another Word 6.0 refugee, complete with nice pixel art 4:3 CRT.

In Windows 10, Wordpad and Paint can both bring up the classic Windows 3.x colour picker Window, complete with the inscrutable Custom Colours bit. Although Wordpad is gone in Windows 11 and I don't think the Windows 11 Paint has the classic picker. It still (IIRC) has a colour arrangement in its new picker that is based on the classic pickers default colour set. Which were chosen because they dither nicely to 16 colours with the Windows 3.x dither algorithm.

Re: How did the Win 95 user interface code get brought to the Windows NT code base?

#74

moving changes from Windows 95 to Windows NT involved manually doing three-way merges for all of the files that changed since the last drop. I suspect that this manual process was largely automated, but it was not as simple as a git merge. The first release of git was in 2005, around a decade after Windows 95.

Funny how fast Git became entrenched as the way of doing things, though. Around 2010 I said in passing, in a forum discussion about how a FOSS project was getting along, “…you’d think someone could send in a patch…”, and I immediately got flamed by several people because no one used patches any more.

> Funny how fast Git became entrenched as the way of doing things, though.

It just really highlights how much better BitKeeper and then Git's design was compared to what came before. You then pile on being free/OSS, and being "proven" by an extremely large, well known, and successful project on top, and you have yourself explosive growth.

There are developers around these days who never had the displeasure of using the pre-Git source control offerings; it was rough.

Re: How did the Win 95 user interface code get brought to the Windows NT code base?

#75

What's the reason for moving from ASCII CHAR to UTF16 WCHAR rather than UTF8 CHAR? I wouldn't think any parts of the codebase that don't need to render the string or worry about character counts would need to be modified. Edit: https://devblogs.microsoft.com/oldnewthing/20190830-00/?p=10... seems the justification was that UTF-8 didn't exist yet? Not totally accurate, but it wasn't fully standardized. Also that other…

Oh god, this again. One word: "History". No one thought we would need more than 16 bits (65k chars) to represent all the world's written languages. Then it happened. There must be no less than one thousand individually authored blog posts and technical articles on this matter. Win32, Java, and Qt all suffer from the same UTF-16 internal representation. There has been endless discussion on the matter over the last 10…

The tragic part is how brief the period of time was between “ascii and a mess of code pages” and the problem actually getting solved with Unicode 2.0 and UTF-8.

Unicode 1.0 was in 1991, UTF-8 happened a year later, and Unicode 2.0 (where more than 65,536 characters became “official”, and UTF-8 was the recommended choice) was in 1996.

That means if you were green-fielding a new bit of tech in 1991, you likely decided 16 bits per character was the correct approach. But in 1992 it started to become clear that maybe a variable with encoding (with 8 bits as the base character size) was on the horizon. And by 1996 it was clear that fixed 16-bit characters was a mistake.

But that 5-year window was an extremely critical time in computing history: Windows NT was invented, so was Java, JavaScript, and a bunch of other things. So, too late, huge swaths of what would become today’s technical landscape had set the problem in stone.

UNIXes only use the “right” technical choice because it was already too hard to move from ASCII to 16-bit characters… but laziness in moving off of ASCII ultimately paid off as it became clear that 16-bits per character was the wrong choice in the first place. But otherwise UNIX would have had the same fate.

Re: How did the Win 95 user interface code get brought to the Windows NT code base?

#76
post #56
post #18

It's always funny to me, the more you go into the depth of windows settings, the older the UI that start to show up. Which makes sense, between the "if we change it we break it in some subtle way" and "we don't expose that in UI anymore so the new panel doesn't have it". My understanding is that windows want to move to a "you can't configure much of anything, unless you use group policy and then you set everything th…

One thing I appreciate about Windows is (in my experience at least) you almost never have to go into the command line to change a weird setting. There's always a toggle in the GUI somewhere . I mean, I'll use the command line if I have to... I just like the fact that the supported options are enumerated visually; I don't have to worry I'll break something. Also, I can peruse through a place like the group policy edit…

The equivalent in the win world to obscure command line settings is the registry. There is a whole heap of documented and undocumented config in there. 99% of the time you don't really need to go in there, but its often the more automatable way and occasionally you will find some fun options.

Re: How did the Win 95 user interface code get brought to the Windows NT code base?

#77
post #56
post #18

It's always funny to me, the more you go into the depth of windows settings, the older the UI that start to show up. Which makes sense, between the "if we change it we break it in some subtle way" and "we don't expose that in UI anymore so the new panel doesn't have it". My understanding is that windows want to move to a "you can't configure much of anything, unless you use group policy and then you set everything th…

One thing I appreciate about Windows is (in my experience at least) you almost never have to go into the command line to change a weird setting. There's always a toggle in the GUI somewhere . I mean, I'll use the command line if I have to... I just like the fact that the supported options are enumerated visually; I don't have to worry I'll break something. Also, I can peruse through a place like the group policy edit…

I appreciate linux for the inverse reason. Because everything is either a nice text based config file or a command line tool, scripting changes to settings and automating things is a breeze.

Re: How did the Win 95 user interface code get brought to the Windows NT code base?

#78

@dang: It would be nice if we can add an exception to these URLs. Currently, the domain hint only says: "microsoft.com". It would be better if it said: "devblogs.microsoft.com/oldnewthing" or "microsoft.com/oldnewthing". I think we did something similar with forbes.com to illuminate when it was a blog (which are frequently low quality), instead of the official media website.

[deleted]

Re: How did the Win 95 user interface code get brought to the Windows NT code base?

#79
post #56
post #18

It's always funny to me, the more you go into the depth of windows settings, the older the UI that start to show up. Which makes sense, between the "if we change it we break it in some subtle way" and "we don't expose that in UI anymore so the new panel doesn't have it". My understanding is that windows want to move to a "you can't configure much of anything, unless you use group policy and then you set everything th…

One thing I appreciate about Windows is (in my experience at least) you almost never have to go into the command line to change a weird setting. There's always a toggle in the GUI somewhere . I mean, I'll use the command line if I have to... I just like the fact that the supported options are enumerated visually; I don't have to worry I'll break something. Also, I can peruse through a place like the group policy edit…

I agree

as a long time windows user, I wish linux copied this feature more

Re: How did the Win 95 user interface code get brought to the Windows NT code base?

#80
post #76
post #56

Earlier quoted context omitted.

One thing I appreciate about Windows is (in my experience at least) you almost never have to go into the command line to change a weird setting. There's always a toggle in the GUI somewhere . I mean, I'll use the command line if I have to... I just like the fact that the supported options are enumerated visually; I don't have to worry I'll break something. Also, I can peruse through a place like the group policy edit…

The equivalent in the win world to obscure command line settings is the registry. There is a whole heap of documented and undocumented config in there. 99% of the time you don't really need to go in there, but its often the more automatable way and occasionally you will find some fun options.

and unsuprisingly that's considered one of the worst parts of windows
Post reply on HN