Hacker News Reader

Comment by ChrisSD | Hacker News Reader

I'm curious why you think Win95 wasn't a 32bit OS?

It was still possible to use "real mode" (16-bit DOS) device drivers with Win95. [1] I believe there was a 32-bit kernel running on top of this 16-bit foundation, but it was definitely a hybrid arrangement. User space processes definitely ran in 32-bit "protected mode", and 16-bit legacy processes ran in their own protected address space when run from inside Win95 - with the 32-bit OS kernel taking the place of what would normally have been the interplay of BIOS and DOS, handling the interrupts routinely generated by 16-bit DOS software for making what we would now call syscalls.

I believe much of this was already in place with Windows 3.1(1)'s 386 enhanced mode and Win32s, although from memory Windows 95 moved far more device drivers into the 32-bit kernel. Presumably this was enabled by not having to be able to end the windowing session and quit back to DOS without rebooting.

[1] I seem to remember CD-ROM drive controller drivers being particularly common culprits in this regard, with virtual mode device drivers often being unavailable, so you had to use real mode drivers in config.sys even on Win9x. Yes, back in the day of single-, double-, and quad-speed CD-ROM drives, you typically had an ISA card with a custom controller that then connected to the CD-ROM drive via an "I can't believe it's not IDE" ribbon cable. Only later did we get ATAPI and hard drives and optical drives could use the same controller and bus. (Sound cards often had an on-board CD-ROM drive controller and ribbon cable connector around that time.)

I agree with most of what you said except for the statement that "there was a 32-bit kernel running on top of this 16-bit foundation". The 32-bit kernel didn't run on top of 16-bit anything. If anything it ran on top of the 32-bit VMM (virtual machine manager), as did the DOS compatibility layer.

> Presumably this was enabled by not having to be able to end the windowing session and quit back to DOS without rebooting.

The original "It's now safe to turn off your computer" screen after shutting down windows 95 is actually just a dos prompt.

You cannot see it, because the computer was left in a graphics mode, but if you can blindly type a command to switch graphics mode you're back at a normal DOS prompt.

IIRC, the accurate statement is that Win95 wasn't pure 32-bit.

In Win9x/Me, the core of the OS (the VMM) is 32-bit (which was true even in Windows 3.x in 386 Enhanced mode.) But, some other parts of the OS remained 16-bit code, and 32-bit apps will sometimes end up invoking 16-bit code via thunks when calling OS APIs.

By contrast, NT-based Windows, a 32-bit app will never invoke any 16-bit code. The only scenario in which 16-bit code would ever run would be when running a legacy 16-bit app.

(Someone please correct me if I'm remembering this wrong.)

Hm, if you were using 32bit applications and 32bit drivers then you wouldn't touch 16bit code (unless of course you did so explicitly).

However there were commonly used built-in dos utilities that were 16bit so if you called out to any of those then obviously you would invoke 16bit code.

One other difference: on Win9x/Me, it was possible for a 32-bit process to load a 16-bit DLL. It was a bit convoluted, in that you needed to create a 32-bit companion DLL which mediated between the 32-bit process and the 16-bit DLL, but it was supported – known as "flat thunking".

By contrast, Windows NT doesn't support 32-bit processes loading 16-bit DLLs, although it does support the reverse (16-bit processes loading 32-bit DLLs – "general thunking")

http://rgmroman.narod.ru/flthunk.htm

I'm not sure how widely this facility, of loading 16-bit DLLs into 32-bit processes, was used. I thought, Microsoft actually used it internally in implementing parts of Win95, but I could be misremembering that.

It wasn't entirely 32bit. The core certainly was, but large chunks of the UI portions were still 16-bit hence for example there was a limit of 16,386 GDI objects across the whole OS so you would get resource depletion errors with many programs running especially if one or more of them "leaked" GDI handles. 16,386 comes from the fact that while they were four-byte (32-bit) values they were stared in a single 64Kbyte byte block of memory (the largest block byte-wise addressable by a single 16-bit register).

Sure there were still some data structures that were limited by being designed in the old 16bit era. Fun fact: even today kernel "Unicode strings" are limited to a length that can be held in a signed 16bit value. Fortunately 32,767 is enough for anybody so it was never changed.

> Sure there were still some data structure

IIRC it was more than just data structures and that other chunks of GDI were 16-bit, in part due to problems with 32-bit driver support for graphics hardware at the time.

Total tangent, but this reminds me of the old Windows 95 joke: 32-bit extensions and a graphical shell for a 16-bit patch for an 8-bit operating system originally coded for a 4-bit microprocessor by a 2-bit company that can’t stand 1 bit of competition.

https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24...

Reply on news.ycombinator.com