At work we're still running a QuickBasic DOS app in Windows 7 32bit using
WOW.EXE and NTVDM.EXE. Vista and Win7 did change some things that caused us
problems but they were things like write access to the root of the C drive.
The 64 bit versions of Vista and Win 7 don't have any WOW.EXE or NTVDM.EXE
at all.
On 23 April 2015 at 01:52, <mark at markesystems.com> wrote:
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