Tweedle Dumb wrote on 2020-05-21, 13:58:

I can't get a beat on how the A20 gate is supposed to behave under Microsoft Virtual PC. I'm trying to get a 16-bits DPMI progra […]
Show full quote

I can't get a beat on how the A20 gate is supposed to behave under Microsoft Virtual PC. I'm trying to get a 16-bits DPMI program running under MS-DOS as a VPC 2007 guest provisioned with 16MB RAM. The DPMI tests all failed under VPC 2007, although the exact same configuration seems to work as expected under VirtualBox. But VirtualBox doesn't have the DOS guest additions, so I'm trying to (hopefully) get it working with VPC.
Booting the VPC MS-DOS guest 'clean' (i.e. no config files processed at boot), and with only HIMEM.SYS, both yield the same errors. It seems in both cases the DPMI configuration utility simply cannot control the virtual PC's A20 line, complaining that the A20 is already enabled and that it can't be disabled. Again, this occurs when the DOS virtual machine is booted clean, as well as when only HIMEM.SYS gets loaded.
However...I recently got that DPMI configurator to run perfectly in Virtual PC 2007 by adding the line: DEVICE=EMM386.EXE NOEMS to my DOS CONFIG.SYS file, just after HIMEM.SYS get loaded. But EMM386 is known to cause problems with certain Virtual PC guest additions (the useful FSHARE utility is often cited as being problematic when run with EMM386) and is contraindicated, so I'd like to avoid using this method if at all possible.
Can someone please shed some light on how Virtual PC differs in it's A20 handling when compared with other emulators and/or physical PCs? I am also at a loss to explain how EMM386 makes the difference with Virtual PC, but doesn't seem to be required with VirtualBox.

What DOS Extender is your application using ?

darry wrote on 2020-05-22, 01:20:

Tweedle Dumb wrote on 2020-05-21, 13:58:

I can't get a beat on how the A20 gate is supposed to behave under Microsoft Virtual PC. I'm trying to get a 16-bits DPMI progra […]
Show full quote

I can't get a beat on how the A20 gate is supposed to behave under Microsoft Virtual PC. I'm trying to get a 16-bits DPMI program running under MS-DOS as a VPC 2007 guest provisioned with 16MB RAM. The DPMI tests all failed under VPC 2007, although the exact same configuration seems to work as expected under VirtualBox. But VirtualBox doesn't have the DOS guest additions, so I'm trying to (hopefully) get it working with VPC.
Booting the VPC MS-DOS guest 'clean' (i.e. no config files processed at boot), and with only HIMEM.SYS, both yield the same errors. It seems in both cases the DPMI configuration utility simply cannot control the virtual PC's A20 line, complaining that the A20 is already enabled and that it can't be disabled. Again, this occurs when the DOS virtual machine is booted clean, as well as when only HIMEM.SYS gets loaded.
However...I recently got that DPMI configurator to run perfectly in Virtual PC 2007 by adding the line: DEVICE=EMM386.EXE NOEMS to my DOS CONFIG.SYS file, just after HIMEM.SYS get loaded. But EMM386 is known to cause problems with certain Virtual PC guest additions (the useful FSHARE utility is often cited as being problematic when run with EMM386) and is contraindicated, so I'd like to avoid using this method if at all possible.
Can someone please shed some light on how Virtual PC differs in it's A20 handling when compared with other emulators and/or physical PCs? I am also at a loss to explain how EMM386 makes the difference with Virtual PC, but doesn't seem to be required with VirtualBox.

What DOS Extender is your application using ?

It's DPMIINST.EXE from Borland C++ 3.1. It's actually a configurator, but trying to run the IDE causes the VM to hang.

Long shot : are you running MS-DOS version 7.0 or higher ? That will automatically load himem.sys , even if absent from config.sys , and load DOS high .
You need to add noauto to your DOS= statement in config.sys to avoid that .
E.G. DOS=NOAUTO

According to https://community.idera.com/developer-tools/b … uring-borland-c

1In particular, the line DOS=HIGH, or any other
2devices that get loaded high, in your config.sys
3will cause DPMIINST.EXE to not be able to run.
4DPMIINST.EXE needs to be able to access high
5memory and if anything else is loaded in high
6memory, it will not be allowed to.  DPMIINST.EXE
7is found in your Borlandc(or tc)\bin directory.
8Once you have done a clean boot (see section on
9Booting Clean) and are in the bin directory type
10DPMIINST and follow the instructions it gives you .

I'm guessing that the reason it works with EMM386 is because it provide a VCPI interface and I am, again guessing, that the program you're running can work with that .

Tweedle Dumb wrote on 2020-05-21, 13:58:

It seems in both cases the DPMI configuration utility simply cannot control the virtual PC's A20 line, complaining that the A20 is already enabled and that it can't be disabled.

This would imply that the emulator does not implement the behavior of A20Gate, whether it is the standard IBM PC AT method controlled by KBC port 60h/64h or the FAST_A20 implementation using port 92h. When there is no A20GATE, the address simply won't wrap around at 1MB boundary. It could be faulty logic in the DPMI implementation that refuses to work when A20Gate was already enabled, because for protected-mode software A20Gate should be enabled and nothing could possibly go wrong when A20Gate couldn't be disabled other than returning failed status for DPMI APIs that tried to disable A20Gate as long as the software does not depend on the address wrap-around of A20Gate. No protected-mode software in their sane mind would ever do that.

EMM386 can emulate the behavior of A20Gate simply because it can do port trapping when running DOS in V86 mode. The real A20Gate would have always stayed enabled for EMM386 and it would trap any access to it to change the memory mapping in MMU to emulate address wrap-around.

darry wrote on 2020-05-22, 01:45:

Long shot : are you running MS-DOS version 7.0 or higher ? That will automatically load himem.sys , even if absent from config.s […]
Show full quote

Long shot : are you running MS-DOS version 7.0 or higher ? That will automatically load himem.sys , even if absent from config.sys , and load DOS high .
You need to add noauto to your DOS= statement in config.sys to avoid that .
E.G. DOS=NOAUTO

According to https://community.idera.com/developer-tools/b … uring-borland-c

Copy code to clipboard

1In particular, the line DOS=HIGH, or any other
2devices that get loaded high, in your config.sys
3will cause DPMIINST.EXE to not be able to run.
4DPMIINST.EXE needs to be able to access high
5memory and if anything else is loaded in high
6memory, it will not be allowed to.  DPMIINST.EXE
7is found in your Borlandc(or tc)\bin directory.
8Once you have done a clean boot (see section on
9Booting Clean) and are in the bin directory type
10DPMIINST and follow the instructions it gives you .

I'm guessing that the reason it works with EMM386 is because it provide a VCPI interface and I am, again guessing, that the program you're running can work with that .

Thanks for that excellent pointer. I've actually been experimenting with MS-DOS versions 5.00, 6.22 and 7.10 (from Windows 98) under Virtual PC with the same result, even when booting clean. At least now I know which version of DOS might not be particularly suited to the task I have in mind.
As for EMM386 under VPC 2007: White it does provide VCPI support, it is not recommended (?) to run VPC's DOS guest additions (esp. fshare.exe) while EMM386 is loaded, so I'd like to keep that out of my CONFIG.SYS if at all possible. Microsoft warns that fshare may fail to even load if EMM386 (or another EMM) is active, but some anecdotes from around the net suggest that it might appear to perform in some capacity (i.e. it loads with an EMM present) but data corruption occurs on file transfers. It all sounds very wonky, at any rate.
I'm at a point where I care a little less about getting the IDE running and a bit more about the mechanisms behind it all. DOS is a fascinating rabbit hole, and Virtual PC is my gateway—at least for now.

kjliew wrote on 2020-05-22, 01:52:

This would imply that the emulator does not implement the behavior of A20Gate, whether it is the standard IBM PC AT method controlled by KBC port 60h/64h or the FAST_A20 implementation using port 92h. When there is no A20GATE, the address simply won't wrap around at 1MB boundary. It could be faulty logic in the DPMI implementation that refuses to work when A20Gate was already enabled, because for protected-mode software A20Gate should be enabled and nothing could possibly go wrong when A20Gate couldn't be disabled other than returning failed status for DPMI APIs that tried to disable A20Gate as long as the software does not depend on the address wrap-around of A20Gate. No protected-mode software in their sane mind would ever do that.

EMM386 can emulate the behavior of A20Gate simply because it can do port trapping when running DOS in V86 mode. The real A20Gate would have always stayed enabled for EMM386 and it would trap any access to it to change the memory mapping in MMU to emulate address wrap-around.

Yes, port trapping makes sense. I also suspect VPC 2007 lacks an emulated A20 line, although authoritative (i.e. Microsoft source) documentation on Virtual PC architecture is practically non-existent from Google's viewpoint. Poking around in the BIOS menus didn't reveal options pertaining to any A20, either. Too bad VirtualBox is still behind VPC in areas of terminal emulation and other necessities like CPU throttling.
I've read that many contemporary PCs (not necessarily virtual machines) opt to forego this A20 shebang anyhow. I wonder if VPC 2007 jumped on that trend early? It's looking like VM and software just don't want to to cooperate.