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: 0000000: fb1e 568e c28e da90 2e8c 1e7e 052e 891e ..V........~.... 0000010: 7c05 8ccb 8edb fe06 cf02 33c0 a37e 0090 |.........3..~.. 0000020: 3c07 7204 3c09 7612 8bf2 8b5c 1236 891e <.r.<.v....\.6.. 0000030: ea02 8b5c 1490 9090 061f 8bdf 33c0 8bd0 ...\........3... 0000040: e800 0090 9090 5036 a1ea 0226 3b45 0690 ......P6...&;E.. 0000050: 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 Win3.x does not try to be compatible with them at all, so even making FreeDOS contain the patchable patterns might not be quite enough. Interesting enough, even with INSTANCE loaded, Win3.x still insists on finding 5 required code fragments in the kernel (before trying int 2f.1603 / int 2f.1607.bx=15 / instance.386). I tried debugging the "DOS programs / boxes crash in Win3.1 /s mode" problem, but did not find much. With INSIGHT debugger, I only say that things jumped into the void. With 386SWAT debugger, I noticed that MS EMM386 had modified the page mapping to simulate a DISABLED A20 and that WSWAP had attempted to make DOS "unused" in order to create a new session for the DOS box. But how could I stop EMM386 from simulating disabled A20s? The mapping thing is of course a really fast way (I think DR DOS EMM386 does the same) to simulate A20 state without having to access the real A20. I believe MS EMM386 even has 2 variants of the page table for the first 4 MB and flips between them by changing only a single dword in the page table directory. Even faster than changing the mapping for 16 pages (64 kB), which is still faster than using a real A20 in most cases. There is also special mapping for the last 4k of the main BIOS (to hook the ffff:0 code), and most of the first 4 MB seems to be quite unused / reserved (e.g. 2nd MB not really used, because A20 state could spoil access, then there are some blocks at N*256 kB offset with some BIOS extensions like SCSI SMBIOS although I have it disabled in CMOS... signature is CC 33 CC 33 00 00 00 00 AA 55 AA 55 00 00 00 00 for those blocks). Interesting enough, the free-for-noncommercial-use DPMIONE standalone DPMI 1.0 host (runs Win3.1 /s and supposedly even KRNL386...!) explicitly is documented as most functions EXCEPT the DOS sessions work. I wonder if the sudleyplace people know WHY this is the case. Notice that KRNL386 will not run in FreeDOS + DPMIONE, not even with MS EMM386 ... which is probably because KRNL386 wants to be invoked only by WIN.COM and of course because we have /3 problems anyway. You can get the 386SWAT debugger and DPMIONE and some other goodies at: http://www.sudleyplace.com/ PS: For German keyboards, do not forget the keyb=gr129 load option for 386SWAT. (apart from that, I used default + recommended options + gpskip=all option) Happy debugging. Would be cool if we could kick Win /s DOS boxes to work or even get Win /3 to accept FreeDOS! Eric. PPS: "search for Assembly language pattern" always assumes 16bit code segments, so you have to cheat a bit sometimes in 32bit code segments like Win32 ones. 386SWAT can search for strings, values and Assembly patterns with wildcards :-). ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
