At 11:30 PM 10/8/2005 +0400, Arkady V.Belousov wrote:

MD> We've discussed loading HIMEM at the DOS prompt after CONFIG.SYS processing
MD> before, too.  It's a bad idea that could easily open the floodgates of bug
MD> reports for people wondering why their drivers aren't loading or working
MD> properly,  and why XMS/EMS memory or HMA/UMBs are missing or
MD> misbehaving.

     If himem/emm386 will complain something like "80386 required to run"
(both at command line and, especially, in config.sys) instead
hanging/aborting/misbehaving (as now), this will be much better and prevents

As the front line guy taking most of the tech support on EMM386 (and HIMEM), I herewith state that you are incorrect. HIMEM delayed loading (not EMM386) might have limited utility for a narrow set of circumstances, but not as a general feature. But until someone else takes over and makes the mistake of thinking that normal delayed loading of low-level memory managers post-DOS shell is a good thing -- and subsequently pays the price for their misunderstanding -- it's not going to happen. If and when it does, I hope I'm not around to see that particular train wreck.

MD> As far as EMM386, I am not sure one could ever reliably load EMM386 at the
MD> command prompt post CONFIG.SYS drivers and COMMAND shell, plus a scattering
MD> of AUTOEXEC TSRs.  I am sure I don't want to try.

     Why not? This will be same, as loading in config.sys without dos=umb.

Dynamically under a DOS session forcing a machine from real to V86 mode, directly accessing extended memory handles and configuring memory maps, plus remapping blocks of memory after a bunch of drivers and the kernel has loaded, and probably other issues I forgot, is the same as loading CONFIG.SYS with no dos=umb? A number of device drivers and TSR's might not agree with this assertion, even assuming COMMAND.COM does. And that's not counting the significant number of code rewrites need to make the delayed load process as stable as possible.

Did you think that perhaps it's not so simple since nothing at all in the DOS world normally manages memory this way?

Alternatively, you, Arkady V.Belousov, could add basic configurability to the kernel code for conditional parsing of CONFIG.SYS. It is an idea which passes the test of rational behavior with an overall increase in OS power for everyone. Plus, it shouldn't be a terribly difficult feature to implement, if kept to reasonable minimum.

This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more.
Freedos-user mailing list

Reply via email to