Hi, as suggested by Michael, I tried 386SWAT and would like to
recommend it for those who have no SoftICE at hand... some hints:
- 386SWAT loads as a device driver (quite small in DOS RAM)
- it debugs everything, including Win kernels / protected mode / ...
- it detects if you have 2 PCI/AGP VGA cards. If yes, it BELIEVES that
both are in text mode. Luckily I have some experience with this, so I
was able to force both cards into initialized text mode (otherwise you
simply see nothing on the 2nd - debugging - screen).
- you invoke it with ctrl-alt-numpad5 or ctrl-alt-sysrq, or with a DOS
tool which loads a program and then kicks into the debugger
- it automatically hooks to Win3.x 386 mode as a VxD, even before Win3.x
manages to complain about unsupported DOS version :-). And it traps
the related Fatal_Error message.
Quite nice. Using the different display modes, search tools and breakpoints
I was able to learn more about Win32 loading in Win 3.1 / German this
weekend. For me, the PCI/AGP bus magic for flipping and initializing cards
*crashes* with MS HIMEM (3.07, comes with Win3.1) *unless* you also load
MS EMM386 (4.44, same source), strange. Whatever. Then in Win3.x itself,
there are some checks at - for me - 8028dfec/8028e067/8028e10b: first a
lookup table for known properties (only contains DOS 4.00 it seems),
then looking for sti push ds push si mov es,dx mov ds,dx and doing sth.
with [there-0f], then doing some more pattern searches in a loop (through
17 bits of a bitmask which is 6680 for me and has 5 non-nop calls in a table
for me). The pattern search looks for
mov cs[57e],ds mov cs[57c],bx mov bx,cs mov ds,bx inc b[2cf] xor ax,ax
mov [],ax (and does sth with [there+14]), then for
cmp al,7 jc /4 cmp al,9 jbe /12 mov si,dx mov bx,[si+12] mov ss[2ea],bx
mov bx,[si+14] (unless DOS version is 4: then it is cmp al,7 jc /19
cmp al,9 jbe /27 cmp al,b jnz /11), then for push ax mov ax,ss[2ea]
cmp ax,es[di+??]. All those patterns HAVE TO exist in the DOS kernel,
second part (e.g. 00d2:0), in the first 52 kB of it. Next is a search for
xor ah,ah int 16 pop bx (or if DOS 3.0a OEM 01: xor ax,ax int 16) in
the FIRST part of the kernel (70:0-d1:f for us), but finding that pattern
is not necessary. Third search is a REQUIRED match again, in second part
of the kernel: push es pop ds mov bx,di xor ax,ax mov dx,ax call ,
and things are done with [there+2], [there+33], [there+3c] and [there+1b].
Fourth search is OPTIONAL again: if (some place, not present in FreeDOS it
seems), size 6 kB, contains x: lodsb cmp al,24 jz y mov bl,7 mov ah,e
int 10 jmp x y: jmp y, [there+d] is modified (I guess the endless loop is
broken or a breakpoint is placed at y: jmp y).
FINAL search looks - for FreeDOS - at a list of words at d2:2c3, which is
zero-terminated and must not be longer than 15-e entries. Not sure what
and why happens there, but the list is empty for FreeDOS anyway so the
search is happy and does nothing.
If you want to have some crashing fun, patch some search bait over
some strings in the kernel (e.g. for 2035, use d2:1141) and load INSTANCE:
http://www.coli.uni-sb.de/~eric/instance.zip
(just a weird project, no version number and a wrong help message ;-))
Data file for the patch:
000: fb1e 568e c28e da90 2e8c 1e7e 052e 891e ..V~
010: 7c05 8ccb 8edb fe06 cf02 33c0 a37e 0090 |.3..~..
020: 3c07 7204 3c09 7612 8bf2 8b5c 1236 891e .r..v\.6..
030: ea02 8b5c 1490 9090 061f 8bdf 33c0 8bd0 ...\3...
040: e800 0090 9090 5036 a1ea 0226 3b45 0690 ..P6...;E..
050: 9090 ..
This will get you by the unsupported MS-DOS-version fatal error (at
least the German message is like that, maybe English variant is the
fragmented memory one? Anyway, FreeDOS seems to pass AARD, Win.com is
not tempted at all to show that fake error 2726 message (which is
suppressed in non-beta versions anyway, so you have to debug to measure
the temptation...). So what you do is:
- use MS HIMEM (included with Win 3.1)
- use MS EMM386 (same - only EMM386 with GEMMIS support are accepted)
- load INSTANCE
- debug patch.bin mcs:100 l 52 d2:1141 and maybe also mcs:100 l 52
d2:1232 to have 2 copies :-P
- win /3 /b /d:fsvx
- enjoy the crash X-). The INSTANCE and patch steps only get you past the
compatibility test but of course Win3.x searches for the patterns to add
some hooks or fixes to the code! So because the patch file is not REALLY
part of FreeDOS, the real FreeDOS stays unprepared for cooperation with
Win32, and things crash. Even with indospolling=yes in [386enh] and all
other voodoo to improve stability, you still definitely crash because Win32
is not able to really patch FreeDOS kernel in RAM.
Would be nice if some people could tell me their theories about the nature of
the several mentioned patterns and about what Win3.x tries to do with which
of them. I used PerVMFILES=0 but of course we still have f_nodes and
