Hrm, odd, post the crash the DOSBox command prompt is left in a strange non-responsive state. The prompt is shown and cursor blinks away, but it no longer accepts input.

This game was apparently designed to work in the NTVDM and not real DOS, but you can avoid the pagefault in DOSBox by disabling DPMI 1.0 extensions:

cwsdpmi -x
verge

Optionally, you can use CWSPARAM.EXE to change the run option flags from 0 to 4 (the parameters are written into CWSDPMI.EXE), then you don't have to preload the DPMI server with the -x switch.

Having dealt with the initial pagefault, other problems stemming from NTVDM behaviors may arise. For example, the files xplosion1.wav and xplosion2.wav exceed 8 characters in the filename. If the game tries to access the files with their long names then it may abort, or at least fail to play the sounds.

Gee, I didn't know there were programs like that. I thought the whole point to cwsdpmi was that it could be used in DOS?

In the NTVDM the DPMI server (which does not use the DPMI 1.0 extensions) is built in, so a separate DPMI server like CWSDPMI is not used there. In fact, quite a few games designed for the NTVDM need DPMI but don't include a DPMI server, which is a clear sign that they were not designed to run in real DOS. The linked archive includes CWSDPMI r5 for whatever reason, but the 2000 date stamps and long filenames are another sign.

BTW, the issue also exists in the Ultima Collection's PC port of Akalabeth, and can be worked around in the same way.

ripsaw8080 wrote:

The linked archive includes CWSDPMI r5 for whatever reason, but the 2000 date stamps and long filenames are another sign.

The CWSDPMI (and, probably, DOS4GW) were added by me, as those were the files the program asked for when run in DOSBox. Those were absent in the original archive.

I thought that might be the case; I remember old versions of Adventure Game Studio would ask for cwsdpmi as well (and also not run very well). It's odd that it would ask for something with which it is not particularly compatible.

DOS4GW was probably included, though, as there's no way it would run anywhere without that, if I'm not mistaken.

DPMI client programs written in DJGPP (like this game) have a default stub that will try to load CWSDPMI if a DPMI server is not already present, and then tell you to get CWSDPMI if it's not found. It's analogous to the default stub in Watcom C programs that loads the DOS4GW extender. However, because a DPMI server is already present in the NTVDM you'll neither need nor be asked to get CWSDPMI there.

This game uses DPMI services and does not need an extender, so DOS4GW is an extraneous inclusion.

Thanks for your help, ripsaw! I was very happy to get it running after searching for a solution for almost a day.