While I can’t however speak to the vagaries of VB4 specifically, I’m reasonably certain (having run 16-bit only software on windows 7 and 8) that ll 32-bit versions of windows continue to support NTVDM/16-bit applications. With windows 8 you have to install the subsystem (its not installed by default) but it does work.
Robert Johnson --- Telegram: @alohawolf AIM:AlohaWulf Skype:AlohaWolf Telephone:+1-562-286-4255 C*NET: 18219881 Email:[email protected] Email:[email protected] -- "Follow the path of the unsafe, independent thinker. Expose your ideas to the danger of controversy. Speak your mind and fear less the label of "crackpot" than the stigma of conformity." - Thomas J. Watson Sr. > On May 2, 2016, at 11:43 AM, [email protected] wrote: > >> I have a Visual Basic 4 application that I need to run on modern 64-bit >> hardware I can do this in a VM, but I really need this VM to be wicked >> small, like under a gig. The smallest XP VM I?ve seen is 600MB (which might >> be good) but XP is becoming very hard to source these days. > > VB4 was a bridge between 16-bit Windows 3.1 applications and 32-bit > everything later (such as the DOS-based Win-95, -98, and -ME, and all of the > NT-based operating systems, which is everything else through Win-10 64-bit). > As such, the package included both a 16-bit an 32-bit compiler. If your > application was compiled using the 16-bit version, you're pretty much stuck > with XP-32 or earlier (in a VM, if necessary), as it will automatically spawn > a 16-bit virtual environment (ntvdm.exe) to run the 16-bit applications. > Win7 and beyond, and all 64-bit versions, do not support this feature (I > supported a VB3 application for 20 years; Win7 was what finally broke it for > good.) > > If it was compiled to 32-bit, then you should be pretty much good to go; you > may run into a few insurmountable problems with some now unsupported OCX's. > Other than those, all of the 32-bit code should run fine on anything current. > > If you have the source, you're also in pretty good shape. VB4 is very easy > to port to VB6; there were almost no backward-incompatible features of the > later Visual Basic classic languages. Find an old copy of VB6 SP6, > re-compile it (perhaps replacing some of the failed OCXs with others that > will work - a common one was DBGrid, which is quite easy to replace with > FlexGrid), and you're golden. I currently support just such an application, > and although the development environment requires a couple of tricks to get > working smoothly, the compiled application works just fine on Win10-64. > > Drop me a note off-line if you'd like any additional or more specific help > with this; I have a reasonable amount of experience with just this problem. > > Of course, there are always older versions of Wine... > ~~ > Mark Moulding >
