Visual Basic Question

[mark at markesystems.com]

>> The phrase "standard Windows 16bit DLLs" means Windows 3.1 DLLs. Such 
>> DLL's no longer work in a modern windows. If they directly access the 
>> hardware then they will not work on any NT based windows such as 
>> Windows/2000, Windows/XP, Vista, or 7, 8 or 9. Nor will they work on any 
>> 64-Bit windows full stop. 64-Bit windows does not support 16-bit code. 
>> If you have a Windows/95, 98 or ME environment then the code may work.
>
>They should work with 32 bit versions of windows as the 16 bit thunking 
>layer is still present.  YMMV of course.

Actually, VB3 works perfectly well under all 32-bit versions of Windows up through XP; it breaks at Windows 7 (and presumably Vista).  Under all the NT-based versions (NT, 2000, and XP), Windows launches a virtual machine call NTVDM.EXE (NT Virtual DOS Machine), upon which runs yet another emulator WOW.EXE (Windows on Windows).  This latter emulator presents the non-preemptive message-passing architecture of Windows 3.1 to all the 16-bit Windows applications (like VB3) that run upon it.

This actually worked remarkably well; I’ve personally supported an application for 20 years that is written in VB3, including adding new features all that time – even a Web server!  There was also a technique that allowed calling 32-bit DLLs from the 16-bit application.  There were a couple of bugs, of course, but generally it was a very stable solution to supporting legacy code.  There was even a work-around to NT’s rigorous defense of direct hardware access which continued to work through XP.

Windows 7 broke all that.  (Presumably Vista actually did, but I’ve never seen a Vista system in the wild...)
~~
Mark Moulding