Not at all.... The best way to think of Win32s was that it was analogous to a "DOS Extender", but for Windows. The main point of what it did was to allow the use of a different memory model under an existing operating system. In the case of Windows 3.1x, this really meant eliminating the notion of segments, by widening segment offsets from 16 to 32 bits. In 16-bit Windows, accessing linear structures >64K requires additional pointer arithmetic, which Win32 eliminated.
The way it did this was to hook into the executable loader to add support for the PE binary format used by Windows NT. It also provided a set of shim libraries that took the existing 16-bit Windows API and projected it into the 32-bit address space. The underlying implementation was still 16-bit, but it could now be called from 32-bit code. This essentially meant that Win32s was the subset of Win32 that was in common with Win16 (and so was missing lots of features from Windows NT).
So think about where this puts WfWG3.11:
* So Win32s added a 32-bit executable loader and shim Win32 API libraries.
* Down in the foundation of Windows (since Windows/386) was VMM, which provided 32-bit OS services
* WfWG 3.11 introduced something called "32 Bit File Access", which was a natively 32-bit implementation of the file system running in VMM.
So the original line of Windows development has already made major strides towards being a 32-bit OS, even before Windows 95. What Windows 95 does is build out that 32-bit shim layer, so there are more full fledged 32-bit implementations of more of the Win32 API, and to do that, it also expands VMM to provide the necessary 32-bit services. (For threading and the like). So far more evolutionary than the 'full 32-bit rewrite that it was once viewed to be.
One easy way to see the impact of all this is in Notepad. Notepad is essentially a wrapper around the standard Windows edit control, which stayed implemented in 16-bit code through all of what I've described above. This is why Notepad was always limited to 32K (IIRC) files on these older versions of Windows, and does not have that limitation on versions of Windows that were fully implemented in 32-bit code.
I also tend to think this is a good engineering solution to a tricky problem. Windows 95 was originally intended to run on very small machines... think 8MB or so in a world where you needed 32MB to run Windows NT. Even if they'd had the engineering resources to fully rebuild consumer Windows as 32-bit, there's no way they'd have come close to meeting their memory budget (or their sales targets).
The way it did this was to hook into the executable loader to add support for the PE binary format used by Windows NT. It also provided a set of shim libraries that took the existing 16-bit Windows API and projected it into the 32-bit address space. The underlying implementation was still 16-bit, but it could now be called from 32-bit code. This essentially meant that Win32s was the subset of Win32 that was in common with Win16 (and so was missing lots of features from Windows NT).
So think about where this puts WfWG3.11:
* So Win32s added a 32-bit executable loader and shim Win32 API libraries.
* Down in the foundation of Windows (since Windows/386) was VMM, which provided 32-bit OS services
* WfWG 3.11 introduced something called "32 Bit File Access", which was a natively 32-bit implementation of the file system running in VMM.
So the original line of Windows development has already made major strides towards being a 32-bit OS, even before Windows 95. What Windows 95 does is build out that 32-bit shim layer, so there are more full fledged 32-bit implementations of more of the Win32 API, and to do that, it also expands VMM to provide the necessary 32-bit services. (For threading and the like). So far more evolutionary than the 'full 32-bit rewrite that it was once viewed to be.
One easy way to see the impact of all this is in Notepad. Notepad is essentially a wrapper around the standard Windows edit control, which stayed implemented in 16-bit code through all of what I've described above. This is why Notepad was always limited to 32K (IIRC) files on these older versions of Windows, and does not have that limitation on versions of Windows that were fully implemented in 32-bit code.
I also tend to think this is a good engineering solution to a tricky problem. Windows 95 was originally intended to run on very small machines... think 8MB or so in a world where you needed 32MB to run Windows NT. Even if they'd had the engineering resources to fully rebuild consumer Windows as 32-bit, there's no way they'd have come close to meeting their memory budget (or their sales targets).