← Back to context

Comment by mschaef

3 years ago

> Just one confusion I have: wasn't NT Win 4.0?

NT's first version released as 3.1, to align with the traditional Windows 3.1. Windows NT 3.5 (Code name 'Daytona') was a performance and stability improvement release. You can think of NT 3.1 as the "1.0" release and 3.5 as the "1.1" release.

Windows NT was natively 32-bit, but this was also the same time that the traditional Windows kernel was developing its own story for running 32-bit code. Windows/386 introduced the 386-specific 32-bit underpinnings and Windows 3.1 added something called Win32s. Win32s was an extension to the Windows executable loader and a set of 32-bit libraries that mapped a subset of Win32 calls to the underling Win16 API. Win32s made it possible to take the same 32-bit binary and run it unmodified on both Windows NT and on Windows 3.1. The caveat (and it was a big one) was that you only had access to a very restrictive subset of the Win32 API.

For Windows 95, Microsoft's strategy was mainly to build out more of Win32s. This built on the Windows 3.1/Win32s ability to run 32-bit binaries and added more of the API's that Win32 developers would've been used to from NT.

> The first NT release IIRC was 3.5, which had the same UI style as 3.0-3.2, but with the new kernel.

It's Windows NT 4 that unified the new UI from Windows 95 and the NT kernel. Even then, the system requirements and compatability issues were demanding enough that it took a few releases to make the NT kernel suitable for the mainstream.

Small correction if I may: Windows 3.1 did not add Win32S.

Win32S was an optional extra: a separate download and was never included with any version of Windows 3.x.

Win32S came along sometime later -- I think approximately in the time frame of Windows for Workgroups 3.11.

There were two purposes for Win32S: an official public one, and a secret one.

The official one was that it allowed developers to experiment with the new Win32 API, develop applications for Windows NT but which could be deployed onto Windows 3.1.

The secret reason behind Win32S was that it didn't work very well if Windows 3 was being hosted on top of a different 32-bit operating system. In other words, to be specific, it gave IBM a really hard time supporting Win32S in WinOS2 on top of 32-bit OS/2. So these new Win32S applications wouldn't run on top of IBM's OS/2 2.x. IBM kept finding ways to implement the additional Apis in Win32S, and Microsoft get changing them and putting out new point revisions of Win32S which broke those Apis again on OS/2.

Eventually the final version did this so effectively that as for as I know IBM never managed to get it entirely working.

By the way Win32S is still out there and you can still download it. There are not many reasons that you would want to do that, but there is one: it includes the original demonstration app for Win32S -- Microsoft Freecell.

This 30-year-old binary runs perfectly on Windows 10 64-bit and Windows 11. You can download Win32S, unpack the zip file, and just copy the files called `freecell.*` to wherever you want. Bingo: the original tiny Freecell Game, in place of the bloated advertisement filled one on the Windows store, for nothing. Enjoy.

  • > Small correction if I may: Windows 3.1 did not add Win32S. > > Win32S was an optional extra: a separate download and was never included with any version of Windows 3.x.

    Andrew Schulman (in Unauthorized Windows 95) and Matt Pietrek (in Windows Internals) both describe the Windows 3.1 EXE loader as shipping with special case code for detecting PE executables. Win32s was an add on to Windows 3.1, but Windows 3.1 shipped out of the box with the necessary hook.

    Whether or not that qualifies as Windows 3.1 _adding_ Win32s is a matter of packaging. (But it is why I used the wording I did.)

    > IBM a really hard time supporting Win32S in WinOS2 on top of 32-bit OS/2.

    Interesting, I never imagined Win32s working on OS/2 at all. I didn't use it much, but I always envisioned the Windows on OS/2 2.x as being closer to Standard mode (286) windows, since the Windows VMM probably didn't run on OS/2. But like I said... I didn't use it much.

    Related to this: do you happen to remember Microsoft's earlier solution for 32-bit code on Windows? Predating Win32s, I remember there being a library that allowed allocation of 32-bit memory and jumping to 32-bit code. This code wasn't like Win32s code that had API access (it didn't), but it was a rudimentary way to access 32-bit offsets.

    • You wrote "Windows 3.1" twice there so I'm not sure exactly what you meant.

      I deployed and supported 3.0, 3.1, WfWg 3.1, WfWg 3.11 and Win 3.11.

      AFAICR after some 30y, none of them included Win32S as standard.

      And no, I don't recall any earlier 32-bit binary or API support.

      I think there were some dozen versions; 10 are listed here: https://www.classicdosgames.com/utilities/win9x.html

      ... and that does not include 1.0.

      2 replies →