DOS ain't dead

DPMILD32 issues (DOSX)

As I wrote in other thread @ , I studied/debugged DPMILD32 a bit and found several things that "leave space for improvements" :

- Avoid loading DPMIST32.BIN . How ?

If executable is not supported by DPMILD32, and size is $180...$280 bytes, search it for "find loader DPMILD" and "from loading overlay", and if both are found, just ignore it instead loading

- ;*** if the loader is loaded as overlay (by DPMIST32.BIN)
;*** DS:DX will point to full path of DPMILDXX.EXE
;*** and DS:BX will have path of program to load
;*** (bad design, but cannot be changed anymore)

What exactly is bad design here ?

- Seems DPMILD32 (and also DPMILD32.BIN, and even HDLD32.BIN) do unconditionally support 32-bit NE, while PE is optional
- - Is the 32-bit NE useful at all ? Maybe it could get kicked
- - Seems that for a PE, DPMILD32 (if PE-enabled at all) first tries a NE (open file, read $40 bytes, test for MZ, read next EXE position at $3C, seek (and fail ) , read, compare against "NE", close file), and then retries with PE (reopen and repeat all the fun). This could be optimized at least
- - NE code is hard-merged into main module, PE is separate - probably could be better also ...

- Spawning still doesn't work at all, see shot:

Fails with CC386 as well as with FreeBASIC

What's wrong here ?

- Don't enable the LONG MODE

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