DOS ain't dead

startup rules (Developers)

posted by kerravon, Ligao, Free World North, 28.11.2022, 23:06

> > When an MSDOS .exe or .com starts, I believe it is normal for it to free
> > memory not in use.
>
> True MZ executables (with the MZ header) can actually specify min alloc and
> max alloc in their MZ header; DOS will not allocate more memory than
> specified by the executable image size plus max alloc.

I am currently bound by wlink, and I took a look at
one of my programs and see:

DGROUP 0dec:0004 0000bb4c

Memory size: 00019a10 (104976.)

C:\devel\pdos\src>hexdump pcomm.exe 0 50
000000 4D5AF801 8B00F700 40008208 FFFFA118 MZ......@.......
000010 00100000 B8B90000 20000000 00000000 ........ .......

minalloc of 882 - I don't have any idea what this
is for. I assume someone thinks it is a good idea
to max out the 64k addressable by DS.

882H = 2178
2178*16 = 34848
65536-34848 = 30688

The DGROUP portion of "executable size" would presumably
not include bss or stack. But const+data is only 13094 = 3326H

Adding BSS would give 43818 = AB2A. So I have no idea
what the rationale for the minalloc is.

setjmp_TEXT CODE AUTO 0000:de90 00000034
CONST DATA DGROUP 0dec:0004 00002424
CONST2 DATA DGROUP 102e:0008 0000003a
_DATA DATA DGROUP 1033:0000 00000ec8
_BSS BSS DGROUP 1120:0000 00007804
STACK STACK DGROUP 18a1:0000 00001000

And the maxalloc is set to FFFF, and I think Watcom
is not alone in doing that, so DOS will give all
memory regardless.

Rather than patch every executable, or change every
linker, it is probably better to do what I am
already doing which is to resize the memory block
myself. And that covers COM files too.

And regardless, I'm still faced with another place
where I need to hardcode the number 4. In order to
set SS to the same as DS, I need to do this:

mov bx,ss
mov ax,ds
sub bx,ax
mov cl,4
shl bx,cl

mov bp, sp
add bp, bx
mov ss, dx
mov sp, bp

So, since I wish to support the Turbo 186 with
8-bit segment shifts, I need to get rid of that
number 4 and make it flexible. And ideally I would
support a completely different segmentation scheme
for PM16.

So, I need to implement a new INT 21H, and only if
it fails do I resort to the hardcoded 4 above.

Any suggestions?

> > I can implement an INT 21H extension (I have a bunch of them, under
> > AH=F6h), and I believe MSDOS is designed to set the carry flag if it
> gets
> > an INT 21H for a function that it doesn't recognize.
>
> Actually, high functions (including service 71h subfunctions on many
> versions of DOS) will not set CY to indicate an unsupported function.
> Instead, they will set al to zero and leave CF unchanged. You can handle
> this case with an explicit stc before the int 21h in order to make sure you
> get CY if unsupported.

Thanks. I have modified PDOS/86 to start adding
AL=0 support.

BFN. Paul.

Complete thread:

• startup rules - kerravon, 24.11.2022, 22:47
  • startup rules - kerravon, 24.11.2022, 23:04
  • startup rules - ecm, 25.11.2022, 08:30
    • startup rules - kerravon, 28.11.2022, 23:06
      • startup rules - DosWorld, 29.11.2022, 01:21
        • startup rules - kerravon, 29.11.2022, 02:24
          • startup rules - DosWorld, 29.11.2022, 03:03