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
