At 07:56 AM 7/24/2006 +0200, Japheth wrote: > > But: DOOM does work with the current himem/emm386. > >As for me this is true for the newest versions of himem/emm386 (July 2006) >only. In fact, any DOS4G application didn't work with FD-Emm386 previously >because my machine has 768 MB.
Generally speaking, for PC environments it was not quite as simple as large free memory. Professional DOS4G-bound applications (the far more common DOS/4GW never exhibited the problem as best as I can determine) did work with high free memory in earlier versions on tested environments. For them, it was a matter of specific VCPI/XMS/EMS/raw memory configuration as to when failure would occur. If large memory amounts were sufficient to trigger problems with DOS4G there, detection of the error almost certainly would happened much earlier. >And "do work" doesn't mean "works well". For example, the MIDI music >played in >Doom sounds "strange" with FD-EMM386 on my SB-Live card. > My guess is that this >is due to missing interfaces in Emm386 (apart from the obscure GEMMIS >interface), for example the documented "I/O trapping" interface (int 2Fh, >ax=4A15h). Without a true SB card, I can't duplicate the problem, but I would strongly bet against the Windows-introduced and flavored GEMMIS being used in any meaningful (or at least critical) manner by DOS4G -- or any other DOS extender of notable popularity. Function 4a15h is much more likely, although until two weeks ago I had never verified that anyone actually used the function on a live application. It would be pretty easy to test DOS4G, however. Run a DOS4G application under a debugger, trap the int 2fh interface, and breakpoint on condition ax=4a15h. Unfortunately, I believe this approach will not work here in the absence of a SB card, since card detection and branch past unsupported code likely occurs prior to any I/O permission setup via 4a15h. Your comments raise an important point that is often understressed by developers to endusers. FreeDOS's health depends upon the type of feedback as you have recently provided. It is critical for all users to understand that until a problem they are having is reported and duplicated in a testable environment, it effectively cannot and does not exist with respect to correcting the situation. All current memory manager work has been tracking application incompatibilities via Bugzilla, e-mail, and list, then mitigating any which are found by suggesting user corrections to initial setups (common); making the memory managers work around bugs in applications themselves (infrequent); extending API support (occasional); or fixing actual bugs (fairly rare). When there are no pending verified bug reports, no further development gets done. Already, this has happened for multiple-month stretches at a time. There have not been any major feature enhancements for over a year on any memory managers -- probably closer to two years. Major feature work is complete. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
