Old Souls - VB3 or VB4 on Win7P32

[Tax Shack]

Anyone have experience with Visual Basic 3 or 4 in a Vbox machine?

I don't have a PC with Win7P32, so I don't know if my problems are purely VB under Win7 or VB under VBox; I suspect the former, but I'm looking for help wherever I can find it!

[mpack]

The question is somewhat strange. Visual Basic is not an OS, so you don't run it in VirtualBox. Whether Visual Basic is compatible with whatever OS you choose to install... is not a question for these forums. But, I wouldn't anticipate any problems.

[Tax Shack]

Sorry, I should have said "VB under native Win7 or VB under VBox Win7. I suppose if my problems were only manifested in Vbox Win7, then maybe this post is germane to this forum. I don't have a native Win7 to test under, so I'm just hoping someone has some expertise in running these old apps in Vbox.

[multiOS]

AFAIR Visual Basic 3.0 and 4.0 were 16-bit programs designed to install/run on Windows 3.x and to develop software on that platform, so I would not expect them to be compatible Windows 7 (64-bit) or any other 64-bit 'NT' based release of Windows, but it might just be possible if your Win 7 install is 32-bit though I don't know how useful they would be.

[mpack]

If they are Win16 apps then note that NTVDM (the underlying "Win16 on Win32" emulation layer) is available in all 32bit Windows up to Windows 10 (32bit).

In Win10 (32bit), NTVDM is omitted by default and needs to be enabled using the "Optional Features" panel.

Window 11 I believe only comes in the 64bit version, so no possibility of NTVDM there.

[Tax Shack]

Yep, both VB3 and VB4 should run ok on 32-machines. Since I couldn't get VB3 to act nice, I was going to use VB4 (which is 32-bit), load VB3 projects, save VB4 32-bit projects and make 32-bit executables, which themselves would run under 64-bit as well. It appears than ntdll.dll is crashing and then ntvdm.exe blows. Memory access problems, I guess.

[mpack]

Memory access problems, I guess.

A VM log would answer that. Make sure the VM is fully shut down, then right click it in the manager UI. Select "Show Log" and save "VBox.log" (no other file) to a zip file. Attach the zip here.

[Tax Shack]

Before I give you the log file, just want to make sure you know that the ntdll.dll abend is in the middle of running the VB 4.0 IDE - even in WINXP machine! Vbox is NOT abending. Will the log still help?

[mpack]

The stability of Visual Basic is no concern of mine. Checking how much RAM the host and VM has is my goal.

[Tax Shack]

Here is the log

[fth0]

FWIW, the log messages containing "vboxIPCSessionThread: Session 19840804: Unknown message" are a red herring, can be ignored and were fixed in VirtualBox 6.1.42. I'd suggest to update to the current VirtualBox 6.1.46 nonetheless.

[Tax Shack]

I was finally able to install VB4.0 on a Win7P32 VM. Believe it or not, the memory problem appears to be VB4's inability to handle a large amount of RAM. I guess no one thought about gigabytes way back then. Just by reducing the VM to 750MB, the problem went away! Much easier to reduce the memory with a VM rather than a real PC!

I've had many other issues to deal with since then, but those are stories I'll post on VBForums. Thanks, everyone.

[mpack]

Huh. That's not making much sense to me. VB4 is not handling RAM, the Win7 OS is, and Windows 7-32bit has no problem no matter how much RAM you install - though of course as a 32bit Windows it will ignore anything beyond 4GB (4096MB).

A 16-bit app should not care how much RAM Win7 sees, it should only care about the RAM it has allocated from the NTVDM interface... and using that interface I'm not sure how the VB3/VB4 app could get into trouble. The whole point of NTVDM is to provide a compatibility layer that keeps the 16bit app happy.

If you were installing Win9x and allocating too much RAM to the VM I could see it - that can and does happen.

But I don't understand this one.

[Tax Shack]

What little I gleaned from research was that VB4 was reading memory levels and barfed at the higher amounts available by interpreting the level as a negative number. It was recommended as a solution and it fixed my problem.

I also thought of another VM tweak that helped. The Setup Wizard in VB4, which creates install packages for the executables, would fail at initialization with an "invalid property value" error. A solution to this was to make sure a Floppy was specified for the machine and that it was marked Empty. Voila, the wizard worked, although execution of the resulting package was spotty (but not due to any VM environment issue). Note that someone posted not to run the install package on the same machine as VB4 because it supposedly wiped out important parts of VB4 itself. So I've only tested on other VM's.