Win95 had wel degelijk een 16bit onderlaag.
Niet in de zin dat ALLE 32bit calls naar 16bit omgezet werden. Maar wel een aanzienlijk aantal.
En dat was niet voor compatibliteit met win16 en dos maar voor win32. (Omdat het teveel werk was om goed werkende bestaande code het allemaal te herschrijven, zonder dat het prestatiewinst opleverde).
generic thunking is used extensively in WIN32 API implementation of Windows 95/98. For example, a 32-bit USER32.DLL calls functions from a 16-bit USER.EXE, and a 32-bit GDI32.DLL calls functions from a 16-bit GDI.EXE
Ik had zelfs nog juist onthouden dat het o.a. om de gdi.exe ging, dus bovenstaande quote vond ik al snel met even googlen:
http://www.windowsitlibrary.com/Content/356/03/2.html
En dan vind je bv ook het volgende:
The 32-bit Windows API on DOS-Windows 95/98/ME is built on top of the 16-bit Windows kernel. Much of the functionality of the 32-bit API DLLs (kernel32.dll, user32.dll, gdi32.dll, advapi32.dll, and so forth) is provided by thunking from 32-bit to 16-bit and calling into the 16-bit Windows kernel, grabbing a global mutual exclusion semaphore known as "Win16Mutex" (that prevents multiple threads from executing in the 16-bit Windows kernel concurrently) for the duration.
En zelfs microsoft geeft het toe:
http://msdn.microsoft.com/msdnmag/issues/0700/hood/However, the region between 2GB and 3GB is problematic because it's shared across all processes. Key parts of the Win16 system code (that is, USER.EXE and GDI.EXE) are still used in Windows 98, and keep critical data such as the window manager heap in this region. A Dr. Evil-concocted program could bash memory in this area and potentially bring down the whole system. Fire the laser!