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,

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 

Take Surveys. Earn Cash. Influence the Future of IT
Join's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
Freedos-user mailing list

Reply via email to