Hi Michael, some test results and stuff... Generally bad news, sorry. > >Yes, BUT: You still forgot to compile with FORSYS defined, so prf.c still > >outputs to BIOS instead of to (redirectable) DOS.
Quite a while ago, when we had the same discussion, I showed you some documentation (PC DOS stuff afair?) which explicitly states that you can use int 21.01 ... int 21.0c at almost any time. That includes that you can use them from within SYS files and from within device init. Ah. Here it is. You can use system calls 01H-0CH and 30H during the initialization code of the driver. Arkady also clarified that FORSYS means "for the SYS.COM tool". While you are at it, do not forget to fix the wrong call for non-Turbo-C compilers in prf.c, as mentioned. PC DOS 7 Tech: http://www.redbooks.ibm.com/redbooks/pdfs/gg244459.pdf > I didn't forget and I did look at the code. The #define explicitly > indicated for SYS files, use it the way it is set up. One of the original > EMM386 developers did that very much on purpose and with apparent > reason. I'm not changing it out unless and until there is a clear > definitive answer that it will work the DOS way even as a SYS file... > > Only few programs use int 15.87 at all, but the best > >known victim of the problem was FDXMS / FDXXMS... > No officially supported with EMM386 and generally a bad idea to use since > it's rapidly becoming obsolete. As far as anything other than HIMEM, you're > on your own. Might work, might not. In other words, programs like FDAPM which access ACPI tables with help of int 15.87 are "bad", and should be using a full blown multi-kilobyte DOS extender / run in protected mode for that measly "fetch tables" call? Whatever. More problems ahead. I tested several programs with EMM386 2.0, setting X=TEST VDS. Many failed. Most of them did work, however, when I added EMM=20480 to the settings, to disable the EMS / XMS / VCPI memory pool sharing. Some programs still failed now, and only worked with the old EMM386 1.15 properly. Funny enough, Win 3.1 /s worked okay except for the known "DOS boxes crash" problem even with pool sharing. Only diff was that pool sharing on means "crash at once" where EMM=... means "show an error message and halt", if you try to open a DOS box anyway. Quarterdeck Manifest / MFT: The "ems benchmark" hangs (table shows up, but no values are shown, CPU seems to end up in busy loop judging by power consumption) if you use pool sharing. The sharing itself is not detected as such, and (known problem) MFT only reports the XMS 2.0 style amount of free XMS. Lemmings 3d (demo), while running even when I copy it to an XMSDSK first on "normal" EMM386 2.0 mode, crashes in any config as soon as I activate pool sharing. It hangs at the "allocated EMS" text. I mean: It hangs even if I have no caches on and run it from harddisk. GCUBE intro crashes on second call with EMM386 2.0: DOS tells that the MCB at d0cf:0 has been zeroed out. Does not happen with EMM386 1.15... If I enable pool sharing, GCUBE hangs right at the start. GASOLINE 1999 demo (PMODE/W 1.33) hangs at once if pool sharing is on. CTSTOAST 1996 demo (when started with DOS32a) hangs at once if pool sharing is on. The DOS version of the DESCENT game (DOS4GW) hangs at once if pool sharing is on. Same for Jazz Jackrabbit (RTM/DPMI16BI) game and the AuGoS Go player (same DOS extender). For AuGoS, things are even worse: With pool sharing disabled, if you let the computer play against him- self (press ESC to abort, then select No for the log storage, etc.), the game reboots as soon as the first "Musterverarbeitung" step starts. Only downgrading to EMM386 1.15 fixes that problem. I hope that helps with debugging EMM386 2.0 - you should probably start with debugging MFT and GCUBE interaction, as those are the smallest apps, and as they have two different problem intensities: MFT EMS bench hangs only if pool sharing is on, while GCUBE crashes if you run it two times (broken UMB MCB chain) even if pool sharing is off. With pool sharing being on, GCUBE hangs right away. On the other hand, GCUBE works fine with EMM386 1.15 (as does of course MFT). Eric PS: MFT tells that 32672k of 32768k EMS are avail if pool sharing is on, maybe that should be somewhat less than 32768 to avoid sign probs? PPS: Any CWSDPMI program, like DOSFSCK or Info-ZIP (the 32bit versions / components of it, I think FreeDOS by default includes the 32bit ZIP but 16bit UNZIP or sth.) hang at once if pools are shared. ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
