;
; DPMIST32.ASM
;
; END.
    

[code]
; "critical" improvements (added 80386 test, size reduction, reduced
; assumptions about DOS behaving nicely, added date, made code more "flat",
; and, most notably, reduced compiling cost drastically) by DOS386

Regrettably my size reduction by 32 bytes will not help over crappy PE loader implementation in NT/XP - such patched apps will no longer work there if total size of ALL headers (MZ header, MZ code, PE header, NT optional header, sectional header, ...) is > then file align ... this means for file align of $200 the stub would have to be cca < $C0 bytes ... no space for any useful code ... and with existing $200/$1E0 stubs, file align of $400 is the minimum The bugginess is very random, from "Not a valid Win32 application", through "Failure to initialize at 43987373984" up to silent abort. Original quality from M$

I'm wondering why you can't just extend the header by 0x200 bytes and shift down the rest of the data. Is there some basic flaw in the loader? I have seen many PE files with lots of sections that make the header large.

I can understand if the header goes over the page alignment (0x1000), then you would have much trouble with relocating the following code and data, but as long as the total header size stays under 0x1000 then what is the cause of the problem?

;filename BigStub-Stub.asm
format MZ
segment zz
entry zz:0
stack 128
heap 0
push cs
pop ds
mov ah,9
mov dx,message
int 21h
mov ax,4cffh
int 21h
message:
db 'Windows 95 or higher required for this program!',0dh,0ah,'$'
db 63 shl 10 dup 0xaa    

;filename BigStub-App.asm

format PE GUI 4.0 on 'BigStub-Stub.exe'

include 'win32ax.inc'

.code

  start:
   invoke  MessageBox,HWND_DESKTOP,"Hi! I'm the example program!","Win32 Assembly",MB_OK
  invoke  ExitProcess,0

.end start    

4. Known Problems

If the new stub written to a binary is larger than the old one,
the binary may become unloadable by the Windows NT/XP loader. On
these systems the header may not become larger than the lowest RVA
in the section table (error message is "access denied"). This should
be no issue with DPMIST32.BIN, which just is 200h bytes long, but
may be a problem if the new stub is to be DPMILD32.BIN.

No expert is safe from criminal bugs, and you shouldn't trust anybody

I have never met such problem - with fasm's "format PE on 'stub.exe'" feature I was able to combine even quite large DOS programs with Win32 ones

.
... and, PESTUB has bug with not increasing SizeOfHeaders (Commented out ? Not default ?) - it "trashes" my executable as well as all (most) executables coming from FASM (file align=$200).

...

Now, we have following PESTUB issues:

- Doesn't adjust SizeOfHeaders. Why ?

- Using non-8086 compatible instructions without testing before (BUG, minor, 1/2 point for me)
- In your "HEX8" routine, you use "10h", but should be a decimal 10 (BUG, 1 point for me)
- Useless calculations with constants (BUG, minor, 1/2 point for me)
- "Looping-BUG", "RC from overlay" is almost dead code and doesn't really work, accepts happily broken DPMILD32.EXE (BUG, critical, at least 2 points for me )

             and  al,$0F
             cmp  al,$10
             sbb  al,$69
             das              ; Digital Attack System
             stosb            ; [ES:DI]
             ret
    

Using "non-8086 compatible instructions" is not a bug. The test for 8086 cpu is intentionally missing. It is documented - and a matter of course - that hx - a DOS extender - won't run on a 8086 system.

; Copyright (C) 1998 DJ Delorie, see COPYING.DJ for details
; * Some code must run on a 8088 without crashing it.

don't accept the "useless calculations" fix, since it is at best an optimization

don't accept the "looping bug". First, it's not included in your 02/19 version

it works with a valid DPMILD32.EXE

and relies on DOS to return errors.

but this doesn't make the current implementation "buggy"

Even worse, in your 19/02 version (which you - wisely! - deleted in the meantime), there is

which makes me doubt that the one bug which is acceptable was indeed fixed in THAT version already.

Bug or not bug

Code that doesn't do what it probably was supposed to ...

YES, I deleted "wisely" the version ... because it was buggy ... and it's no secret that that those bugs were not yet fixed there ...

it will not intimidate me.

IMO deleting posts after other people did respond to it is not very polite, because it makes the responses incomprehensible.