> You mean 16-bit console apps running in 32-bit OS, or 32-bit console apps using 16-bit I/O? I mean on Win9x/Me, 32-bit console apps are forced to use 16-bit

> You mean 16-bit console apps running in 32-bit OS, or 32-bit console apps using 16-bit I/O? I mean on Win9x/Me, 32-bit console apps are forced to use 16-bit I/O. The 32-bit console APIs are implemented using 16-bit MS-DOS IO via the VCOND VXD and CONAGENT.EXE. There was never a 16-bit console API for Windows, so all 16-bit console apps were either DOS or OS/2 1.x. (NT originally could run OS/2 1.x console apps, although the support was withdrawn at some point; 9x/Me never could, except for family mode executables.) > I only recently learned about "DLL surrogates" and Windows mechanisms for mixing 32-bit and 64-bit code by having 32-bit DLL proxied by a system-provided executable. I even wrote a DLL-proxying executable once, because the nature of legacy proprietary code is that sometimes you really need that 32-bit DLL the vendor, for whatever reason, refuses to rebuild for 64-bits... That’s something I’d be interested to know more about. Microsoft put a lot of effort into ensuring interoperability between 16-bit and 32-bit code, but when it came to do the same for 32-bit/64-bit, decided not to