Hi all,

If you've ever tried using hdpmi32 with a djgpp program, you may have
noticed some strange behavior. The program first fails to run with
"Load error: no DPMI", but on the second try, it suddenly works. Then
a third invocation fails again, the fourth runs fine, etc.

When you rename 'hdpmi32.exe' to 'cwsdpmi.exe', your program seems to
run consistently. But this is only because there is a second (real)
cwsdpmi in your PATH somewhere. What really happens, is that your
program alternates between running under hdpmi and cwsdpmi.

I finally figured out why this happens, and it's very simple: hdpmi uses
the exit status to indicate if it was loaded via xms, vcpi, or int15.
And the djgpp stub considers any non-zero exit status to be a failure,
so it keeps searching PATH until cwsdpmi is found, which always returns
zero.

For a possible solution, I would suggest to ignore the return status
from the host, and just check int 2f/1687 after every exec. As an added
bonus, this saves 13 bytes of stub space.

--- a/src/stub/stub.asm
+++ b/src/stub/stub.asm
@@ -199,33 +199,61 @@ not_path:
;-----------------------------------------------------------------------------
; Get DPMI information before doing anything 386-specific

+ push di
+ xor cx, cx
+ ; Set up loadname in case of no DPMI.
+ ; First try current dir.
+ xor ah, ah ; Copy until this character (=0)
+ call store_env_string ; copy stub image to "loadname"
+ mov si, bx ; remove name so we can add DPMI name
+ mov di, [path_off] ; Pointer to path contents (next try) +check_dpmi:
push es
push di
- xor cx, cx ; flag for load attempt set cx = 0
- jz @f2 ; We always jump, shorter than jmp -@b1:
- mov al, 110
- mov dx, msg_no_dpmi
- jmpl error
-@b2:
- or cx, cx
- jnz @b1 ; we already tried load once before
- inc cx
- call load_dpmi
- jc @b1
-@f2:
+ push si
+ push cx
mov ax, 0x1687 ; get DPMI entry point
int 0x2f
+ pop cx
or ax, ax
- jnz @b2 ; if 0 then it's there
+ jnz @f1 ; if 0 then it's the