DOS ain't dead

Japheth wrote ( http://japheth.de/HX.html ) :

> The MZ format compared to the PE format has some limitations, though.
> - applications cannot run in a true flat (=zero-based) memory model

Recently, something very BAD happened:

I hacked on the USEDPMI.ASM example (generously discussed in other forum ) - and got a true flat ZERO-based memory model !!! With very marginal adjustments only What's wrong ? Is the statement correct ? Did I miss something ? Where is the limitation supposed to come from ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> I hacked on the USEDPMI.ASM example (generously discussed in other forum
> ) - and got a true flat ZERO-based memory model !!!
> With very marginal adjustments only What's wrong ? Is the
> statement correct ? Did I miss something ? Where is the limitation
> supposed to come from ?

So please post your adjustments!

the problem is that "near32" addresses (=offsets) in MZ are always relative to the address the binary is loaded to, and this address is never 0 in DOS.

However, due to the way Intel cpus handle "call" and "jmp" opcodes it is possible to set the base of CS, SS, DS, ES to 0 and indeed run "non-flat" code then ... if it avoids certain things. Among these "certain things" is access to global variables, so it won't be a true option usually.

---
MS-DOS forever!

> So please post your adjustments!

; FASM example of writing 32-bit program using DPMI
; True FLAT ZERO based memory model
; requires a GOOD DPMI host installed in system

format MZ
heap 0                                  ; no additional memory
use16

        push    cs
        pop     ds
        push    cs
        pop     ax
        mov     [ss:0],ax

        mov     ax,1687h
        int     2Fh
        or      ax,ax                   ; DPMI installed?
        jnz     error
        test    bl,1                    ; 32-bit programs supported?
        jz      error
        mov     word [mode_switch],di
        mov     word [mode_switch+2],es
        mov     bx,si                   ; allocate memory for DPMI data
        mov     ah,48h
        int     21h
        jc      error
        mov     es,ax
        mov     ax,1
        call    far [mode_switch]       ; switch to protected mode
        jc      error

        mov     cx,1
        xor     ax,ax
        int     31h                     ; allocate descriptor for code
        mov     si,ax
        xor     ax,ax
        int     31h                     ; allocate descriptor for data

        mov     di,ax
        mov     dx,cs
        lar     cx,dx
        shr     cx,8
        or      cx,0C000h
        mov     bx,si
        mov     ax,9
        int     31h                     ; set code descriptor access rights
        mov     dx,ds
        lar     cx,dx
        shr     cx,8
        or      cx,0C000h
        mov     bx,di
        int     31h                     ; set data descriptor access rights

        xor     cx,cx                   ; & Our ZERO base
        xor     dx,dx                   ; &
        mov     es,cx                   ; #
        mov     fs,cx                   ; # Not used by now
        mov     gs,cx                   ; #
        mov     ax,7                    ; set descriptor base address
        int     31h
        mov     bx,si
        int     31h

        mov     cx,$FFFF
        mov     dx,$FFFF
        mov     ax,8                    ; set segment limit to 4 GB
        int     31h
        mov     bx,di
        int     31h

        mov     ds,di
        pushw   0
        pushw   si           ; Will land in CS one day
        mov     cx, [ss:0]
        add     cx, rmcodesizepar
        shl     ecx, 4       ; "paragraph" -> linear
        pushd   ecx          ; Start address in new segment
        retfd

    error:
        mov     ax,4CFFh
        int     21h

  mode_switch dd ?

;
; Padding to 16-byte integer multiply + calculations
;
rmcodeend:     ; No code, just for padding
temp1=rmcodeend mod 16
if (temp1<>0) ; then
  db (16-temp1) dup (0)
end if
rmcodesize:   ; No code, this is the aligned RM code size (starts at 0 !!!)
rmcodesizepar = rmcodesize shr 4 ; In 16-byte "parag" units

use32
org 0

           call lleipbase
lleipbase: pop edx
           lea esi,[edx+txhello-5]
lloop:
        lodsb
        test    al,al
        jz      ldone
        mov     dl,al
        mov     ah,2
        int     $21
        jmp     lloop

ldone:  ud2

txhello db 13,10,'Hello from PM, FLAT ZERO based memory model !',13,10,13,10,0

Done in above ^^^ code:

- ZEROized model
- got rid of MZ-fixup
- probably "fixed" BOCHS crash

ToDo:

- Get rid of 16-bit stack, SS:=DS
- format MZ -> format binary
- Save linear addresses of PSP/DTA/ENV

> the problem is that "near32" addresses (=offsets

IIRC FASM doesn't suffer from offsets

> in MZ are always relative to the address the binary is loaded to,
> and this address is never 0 in DOS.

Very true, but don't see the problem

> However, due to the way Intel cpus handle "call" and "jmp" opcodes it is
> possible to set the base of CS, SS, DS, ES to 0 and indeed run "non-flat"

Or FLAT ?

> code then ... if it avoids certain things. Among these "certain things" is
> access to global variables, so it won't be a true option usually.

Depends how one implements the global variables

Seems to be an issue of fixuping and linking

Question: is it possible / good idea to place a breakpoint at bottom of the stack with INT $31/$0B00 ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Done in above ^^^ code:
>
> - ZEROized model
> - got rid of MZ-fixup
> - probably "fixed" BOCHS crash

Ok, absolute addresses aren't used, so it works.

> IIRC FASM doesn't suffer from offsets

But that's not an assembler specific issue at all. "Offsets" are addresses, and both MASM and FASM use addresses.

> > in MZ are always relative to the address the binary is loaded to,
> > and this address is never 0 in DOS.
>
> Very true, but don't see the problem

Because the MZ format doesn't add a "base" (preferred load address) to the offsets, like PE and LE usually do. So MZ is slightly comparable to PE/LE with a load address of 0.

> Depends how one implements the global variables

Yes, but you cannot control that if you use C or another HLL.

> Question: is it possible / good idea to place a breakpoint at bottom of
> the stack with INT $31/$0B00 ?

It's possible. But there are only 4 hw breakpoints available.

---
MS-DOS forever!

> > Depends how one implements the global variables
>
> Yes, but you cannot control that if you use C or another HLL.

I think I can. Have some pending C code (thanks to ladsoft for making this #!&$#%^&@ language accessible for me at all). OTOH no final evidence before the thing gets released and works

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > > Depends how one implements the global variables
> >
> > Yes, but you cannot control that if you use C or another HLL.
>
> I think I can.

Might be with CC386, but surely not in general.

---
MS-DOS forever!