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
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
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
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. http://solutions.newsforge.com/ibmarch.tmpl
Freedos-user mailing list