• Re: [PATCH] stub: ignore host exit status

    From [via djgpp@delorie.com]" @21:1/5 to J.W. Jagersma on Thu Nov 24 21:35:49 2022
    On 2022-11-23 20:47, J.W. Jagersma wrote:
    [patch omitted]

    Noticed a small bug here, sorry. Will send a v2 soon.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Wed Nov 23 20:47:05 2022
    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
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Wed Jan 25 22:10:28 2023
    On 2023-01-25 00:36, Frank H. Sapone (emoaddict15@gmail.com) [via djgpp@delorie.com] wrote:
    I know you're looking for feedback but I dont use hdpmi32 and don't know of too many others that do except to run some windows console apps under dos.  Cwsdpmi works just fine for djgpp.

    In any case, someone who knows what they're looking at can hopefully chime in.  Just wanted to let you know we're receiving your messages. :)

    Thanks for the message! I think this is an important patch, hopefully someone can review it at some point. Although I suppose this should be fixed on the hdpmi32 side too, so newer hdpmi versions are compatible with old djgpp programs, and new djgpp programs can work with older hdpmi versions.

    As for why someone might want to use hdpmi instead of cwsdpmi, the simple answer is speed - on the few functions I benchmarked, it's over 20 times faster. That can add up on things like allocating memory or PM-RM switches. Plus it implements more (almost all) DPMI 1.0 functions.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)