Hi, I collected some potentially interesting but kind-of-unreadable notes (200+ lines) about Windows and FreeDOS. Might be interesting to read for those who want to use Win3.x in FreeDOS or who want to improve compatibility in this area. I made the notes for myself, but hey, they are English ASCII text, you can try to read them, too ;-).
http://www.coli.uni-sb.de/~eric/stuff/soft/specials/win3.x-dosext-freedos-notes.txt Not mentioned there: The infamous AARD. Story: MS announced Win3.0->3.1 upgrade along with "will not be compat to DR DOS" FUD when DR DOS hit the MS DOS market. To enforce that, they added some hidden checks to the Win 3.1 beta releases. Maybe this is a reference to that check? -> http://www.it-faq.pl/mskb/90/796.HTM "conspirative patch #14" Anyway. AARD was removed from HIMEM / MSD and disabled in WIN. It still is in SETUP and SMARTDRV. As Steve tells that Win3.1 SETUP works in FreeDOS, I assume that FreeDOS passes the check. It is explained in: http://fringe.davesource.com/Fringe/NonZen_Companies/Microsoft/Tactics/1993.09.01.Locks_Out_DrDOS.html (according to another fringe site, this stands for Aaron Reynolds, who wrote it...) http://www.freedos.org/freedos/news/technote/107.html Our AARD overview. According to the kernel history / changelog, we mastered AARD in kernel 2028. (9 Dec 2002). One problem less :-). My main problem with Windows right now is (okay, I do not have any Windows, and I have Wine, so I do not need Windows and I cannot test anything myself) that I believe that we must support INSTANCE DATA interfaces. Either the small int 2f.1603 one or the big (DOS 5+) int 2f.1607.0015.000x one. For MS DOS, Windows has hardcoded answers to 2f.1603 question as fallback for some older versions (Win3.x needs DOS 3.2+ I think). I hope it will not try to apply them to FreeDOS... (if it checks int 21.30 OEM ID, it should take the right conclusions). My idea is that you better use NO TSRs at all except HIMEM (preferrably the one which comes with Win3.x), and that you do not use HMA or UMB and probably not even XMS swap of FreeCOM until int 2f.1607.0015 is implemented in FreeDOS. That interface would allow: - query for DOS kernel driver seg (e.g. 0x70), "patch" locations of saved DS/BX, user id (where except in "commit file" is this used?), critical section hook enable, segment of last non-UMB MCB. - ask DOS to enable hooks (patch itself) -> critical sections, ignore user ID setting, make int 21.3f for STDIN a poll loop, trap win386 sysinit stack fault (?), trap BIOS / DJ mechanism something. - get size of CurrentDirectoryStructure (you know, that thing which has LASTDRIVE entries...) - get instance bitmask -> ask what is instanced (bitmask) -> CDS, System File Table, devicelist, Swappable Data Area - get driver size -> how big is driver at segment ES? That driver size thing should be simple (DOS 4+ system data sub-segments). If SFT is not instanced (seems to be "normal"), then all VMs will share one SFT, I think, so you should not mess with files which were open when you started Windows (from within Windows). SHARE would probably help, but on the other hand it is recommended to NOT use SHARE unless you need it... Not sure what exactly the driver/device list means. Windows at least instances the last "next driver" pointer, to be able to locally install sys drivers while Windows is active, I think. The SDA is that huge infamous data structure which you have to clone in most aspects to be "compatible" to all those programs with "undocumented DOS fehtish". The CDS is... I already told. The critical sections patch means that entering / leaving InDOS state will trigger a call to int 2f.1681 / 2f.1682 respectively, or maybe 2a.800x/810x/82. This blocks task switching during - you guessed it - critical sections. The int 2a style API distinguishes 16 different types of them - each of them must not nest. Most useful types are: 1 kernel/share/dosmgr (for kernel, share and network data structure integrity) 2 kernel/dosmgr (active while calling a sys driver), A CD-ROM redirector (but better try without one first...). Windows 2.x simply looked at the InDOS flag for all this "critical section" stuff. I do not know what exactly that DJ mechanism thing is - I assume it mainly suppresses the message, because Win is no text mode app. Only needed if you trigger the DJ mechanism (i.e. use B: on a one-floppy-drive system) ;-). That poll loop thing sounds easy - default is to check int 16 keyboard BIOS for waiting keys (well, at least inside CON this is done), which would not be appropriate inside Windows. Not sure how to do this exactly... As we support no user-id related stuff, this can probably be ignored. No idea about the "trap win386 sysinit stack fault" thing!??? What is that "saved DS BX" thing?? The SMALLER interface - as an alternative to int 2f.1607.0015 - is only meant for pre-DOS 5 versions of DOS (probably no HMA/UMB support)...: int 2f.1603 returns a data structure which contains pointers to the kernel segment (-> if HMA is used, there would be 2...), STACKS management data (are our STACKS compatible to that? Normal would be an array of stack pointers and flags, which implements a "stack" of N stacks of M bytes size each, from which wrappers for IRQ handlers (which have to start with some standardized first 16 bytes for interrupt sharing support!) can allocate whenever an IRQ occurs. Stacks can even overflow into each other: If your IRQ handlers use 500 bytes stack, but you only allocated STACKS=9,256 then each nested IRQ will eat 2 of the 9 stacks...), and probably most interesting: an array of memory area descriptions to tell where instance data is (I assume all has to be in SDA for DOS 5+!?). Instance data is data which must not be shared between different VMs, and you have 1 VM for Windows itself and 1 more for each DOS box as far as I understand the idea. Programs loaded inside the DOS boxes are "local" anyway (whole 4k page wise), but instance data means up to 32 areas of up to 64k each. This is intended to save memory and time when managing multiple VMs, I believe. Instance data is located when Windows starts and does not change position later. Finally there is GLOBAL data (same for all VMs), which includes the BIOS and the DOS kernel (except instanced areas) and all (you better load none...) TSRs which were loaded before Windows. Does anybody know what NeilSa meant with "DOS memory arena"? Instance data is, at least: 40[13]/2 50[4]/1 0[0]/400, SDA, CDS, SFT-if-possible, STACKS, "last link in SFT table", "device header list", and internal DOS / BIOS tables. The VGA / keyboard / COM / LPT 40[xx] areas are automatically added to the list of instanced stuff. The mouse driver tries to instance DOS mouse driver segment, but you better load no DOS mouse driver. The EMM driver instances the segment of the XMS handler. Windows-aware TSRs can add instance items in response to the init broadcast of Windows, and preserve some data when Windows exits (if they want to). Whatever. Try using WIN /D:SFVX (3.1, no ROM breakpoints, use int 13, do not use UMB area. For WfW 3.11, try /D:TFC (C: no 32bit file access, T: no VxDs at all - there is no real /s mode anymore, and /D:T means no DOS boxes possible). Use /B to create a log file. Avoid shadowed ROM or A20 stuff - or use /D:X. Okay... this mail is already far too long again. I hope I could help to get some people started (Steve/-uso?) with trying to kick Windows a bit :-). And maybe even somebody felt inspired to add int 2f.1603 to the kernel!? For int 2f.1603 or int 2f.1607.0015, we would have to know which areas of DOS state have to be instanced (I believe instancing too much would not hurt except for performance). Would it be an option to "instance" all memory up to - and possibly including - the resident part of the shell? Sure, with DOSDATA=UMB, drivers in UMB, DOS=HIGH, ... things would get a lot more complex. But to get started... "instance first 64k?" X-)). A "quick and dirty" approach for critical sections should be possible, too (something like "InDOS is critical"). Note that the "critical section hook enable" thing was a list of "ret->push ax" patch locations originally but simply points to a boolean var in memory in newer DOS versions. Not to be forgotten is also that 21.3f.stdin poll loop, probably? Ignore the rest and hope the best :-P. Eric PS: I did not mention whether this would be for DOSX (/s, 286 compatible) or WIN386 (/3, WfW) mode. I actually think it is for BOTH (even in /s mode, Steve reported crashing DOS boxes, probably an instance data problem?). Read my online notes to learn about minimal / safe DOS config for Win use. PPS: If you have MS DOS, feel free to ask int 2f.1605 (Win init broadcast) and check whether anything returns extra locations for extra instance data. And ask int 2f.1607.0015.0004 to check which - if any - data structures are reported as instanced by that particular DOS version, and also check int 2f.1607.0015.0000 to get info about kernel instance state / ability and returned "patch table" for that. Interesting would be especially DOS 5/6 and DOS 3.3/4.01 ... ... and what is that SAVEDS / SAVEBX ??? ... ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
