2 ms·
It’s not correct to say it was “really 16-bit”, no, but as Unauthorized Windows 95[1] eloquently demonstrates, neither was Windows 3.1 or 3.11, especially with
by mananaysiempre 1mo ago
It’s not correct to say it was “really 16-bit”, no, but as Unauthorized Windows 95[1] eloquently demonstrates, neither was Windows 3.1 or 3.11, especially with Win32s, and Windows 95 was much more of a direct descendant of that environment that the marketing implied.
And on a more personal note, reading the descriptions of the mixed 16/32-bit architecture always makes me feel conflicted.
On one hand, the technical achievement is somewhere between genius and madness and I’m not sure on which side—not only did they ship a hypervisor in a consumer OS in 1987 (as “Windows/386”), they also flipped a live MS-DOS with an unknown complement of drivers and binary patches from running on live hardware to running inside a(n admittedly unsafe) VM, then proceeded to use those drivers and respect the patches including in applications written for Windows and not MS-DOS. I don’t think I have the sort of arrogance it takes to even think of attempting such acrobatics.
On the other hand, I was there, I grew up on computers that ran Windows 95 and 98, and I remember just how much better Windows 2000 was, how much more comfortable it was to not worry about the system crashing on you every half an hour. Perhaps 95 was a magnificent technical achievement, but it certainly didn’t feel like one to the user. And thus I continue to feel conflicted.
There’s also the question of why, exactly, was NT too heavy to run on contemporary consumer machines. You could say it was bloated, but so was Windows 95: the multiple 16/32-bit mode transitions it took to write to a file certainly weren’t free; and don’t get me started[2] about shipping a COM-based shell, realizing it was too heavy for the minimum RAM requirement, and solving that by shipping a second, stripped-down copy of COM then live-swapping the real one in its place as soon as the fake one became insufficient.
[1] https://www.os2museum.com/wp/book-review-unauthorized-windows-95/ https://www.os2museum.com/wp/book-review-unauthorized-window...
[2] https://devblogs.microsoft.com/oldnewthing/20040705-00/?p=38573 https://devblogs.microsoft.com/oldnewthing/20040705-00/?p=38...
- Grimeton 1mo agoI've always seen Windows 9x as the Win32(s) subsystem running on top of a VM-manager/DOS-Kernel, what it basically is.
- mananaysiempre 1mo agoKinda. There are also the 32-bit bits on top, not (AFAIU) that different from their NT4 counterparts, such as the shell, COM/OLE2, TrueType, OpenGL, etc.; the core Win16 stuff (KERNEL/USER), which the Win32 layer thunks down to and which in turn invokes DOS routines; and the VxDs that intercept various pieces of DOS/BIOS and replace them with 32-bit code (“32-bit disk access”, “32-bit file access”, etc.). Only the first of those is new to Win95.
- devilbunny 1mo agoWin95 OSR2 and Windows 98 Second Edition were actually pretty reliable, unlike early 95, but the first person I knew to own a CD burner called NT his 100-megabyte CD burning software, because 95 and 98 just weren't stable enough (and blanks still expensive enough to care) at I/O.
- mike_hearn 1mo agoWinNT in that era was a microkernel that ran the GUI outside of kernel mode and it was just too slow and too much overhead (copying datastructures etc). Win95 GUI subsystem relied heavily on large shared memory segments and running things in kernel mode. Less safe, but less overhead. You don't need to copy bitmaps around because the GUI can just read them straight out of app RAM.
- ahartmetz 1mo agoI think "bloat" was mostly about RAM at the time. MS went as far as writing new 16 bit code for Windows 95 to save memory.