You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We get an error as shown below, when a simple test program tries to enter DPMI protected mode. It reads:
MS-DOS Prompt
This program has performed an illegal operation and will be terminated. Quit all programs, and then restart your computer.
If the program consistently encounters problems, click the Start button, then select Help, Troubleshooting, and 'If you have trouble running MS-DOS programs'.
[OK] [Details>>]
The program encountered an invalid page exception.
If I run my debugger, lcdebugx.com dpmimini.com then on the first trace step (T command) it informs me that "DPMI entry cannot be hooked!" which is expected on MSWindows 4. However, tracing into the DPMI entrypoint (call far [bp + 00] instruction at offset 0143h) I get an address of FCB8:2F97 with the instruction bytes 63, 38 that disassemble as arpl [bx + si], di. If I try to trace this, the machine crashes in the same way as for running only dpmimini. The error message is exactly the same.
The text was updated successfully, but these errors were encountered:
It is possible that arpl is intentionally used as an instruction that causes a fault in V86 Mode: https://www.felixcloutier.com/x86/arpl says that it should #UD in V86 Mode. So this may be not the cause of the error.
My DPMI test program was in error, it frees and zeroes the environment segment at word [PSP:2Ch] but MSWindows expects this field to be nonzero upon entering DPMI Protected Mode. With this part commented out the DPMI mini program runs fine on its own.
However, when I try to trace the arpl instruction used to enter PM in either lCDebugX (both /D+ and /D- mode) or lDebugX then Windows crashes. Briefly I get a mostly black screen with the outlines of the MS-DOS prompt window in white, then the machine falls back to a memory test apparently done by the ROM-BIOS, which emits some beeps. After pressing F1 several times the machine reboots.
I tested a similar program on an MSWindows 98 SE running on a physical 686 machine and it works just fine after the modification to dpmimini.com. (I didn't test the exact same program on both machines yet.)
ecm-pushbx
changed the title
MSWindows 95: Trying to start a DPMI program crashes the DOS window
MSWindows 95: Trying to trace a DPMI program with lDebugX crashes the OS
May 26, 2024
Running https://www.pcjs.org/software/pcx86/sys/windows/win95/4.00.950/
We get an error as shown below, when a simple test program tries to enter DPMI protected mode. It reads:
Screenshot showing the error:
The dpmimini program is included in the disk image https://pushbx.org/ecm/test/20230813/bcdebugx.img which is unlocked on the server for use as a remote disk for PCjs. The source of the program is in https://hg.pushbx.org/ecm/dpmitest/file/845e876b561e/dpmimini.asm
If I run my debugger,
lcdebugx.com dpmimini.com
then on the first trace step (T
command) it informs me that "DPMI entry cannot be hooked!" which is expected on MSWindows 4. However, tracing into the DPMI entrypoint (call far [bp + 00]
instruction at offset 0143h) I get an address of FCB8:2F97 with the instruction bytes 63, 38 that disassemble asarpl [bx + si], di
. If I try to trace this, the machine crashes in the same way as for running only dpmimini. The error message is exactly the same.The text was updated successfully, but these errors were encountered: