Hi!
8-Окт-2005 16:37 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-user@lists.sourceforge.net:
>>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
>>"floodgates".
MD> As the front line guy taking most of the tech support on EMM386 (and
MD> HIMEM), I herewith state that you are incorrect. HIMEM delayed loading
I _not_ say about loading HIMEM from command line, I say about CPU
detection and preventing load on too old CPUs. Though, I myself think, there
is nothing wrong in loading XMS after DOS load - this will be similar to
loading DOS without DOS=HIGH. Ie. XMS will be available to applications,
whereas DOS itself doesn't uses it.
MD> (not EMM386) might have limited utility for a narrow set of circumstances,
MD> but not as a general feature. But until someone else takes over and makes
MD> the mistake of thinking that normal delayed loading of low-level memory
MD> managers post-DOS shell is a good thing --
I think, this is _not wrong_ thing. Ie., this feature may have limited
usefulness, but there nothing wrong.
MD> and subsequently pays the price
MD> for their misunderstanding -- it's not going to happen. If and when it
MD> does, I hope I'm not around to see that particular train wreck.
May you explain, where you see there "wreck"? Difference between
loading of XMM (not neccessarilly HIMEM) at config.sys and at command line
is that at config.sys, _when DOS=HIGH_ present, DOS reuses HMA after loading
XMM (and starts to control A20). When DOS=HIGH is missing, there are no
differences (ie. loading XMM at command line adds another function to
extended memory beside INT15).
>>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.
MD> Dynamically under a DOS session forcing a machine from real to V86 mode,
Which difference in forcing protected mode at config.sys stage of _DOS
session_ and command line stage of DOS session?
BTW, DOS extenders runs protected mode at command line and there are no
prevents for this from DOS side.
MD> directly accessing extended memory handles and configuring memory maps,
DOS doesn't access extended memory.
MD> plus remapping blocks of memory after a bunch of drivers
Isn't memory remapped only in UMA, which not used before EMM386? And
what prevents to load drivers in config.sys before emm386?
MD> and the kernel has loaded, and probably other issues I forgot, is
MD> the same as loading CONFIG.SYS with no dos=umb?
Yes. If dos=umb is missing, then DOS doesn't checks (includes into MCB
chain) UMBs, if they appear after loading some driver (emm386, umbpci, etc).
Other differences between DOS stages (config.sys or command line) doesn't
exist.
MD> A number of device drivers and TSR's might not
MD> agree with this assertion,
Which "this assertion"? Programs (applications) just use INT67 - and
where difference if this interface appear at config.sys or command line
stage?
MD> even assuming COMMAND.COM does. And that's not
MD> counting the significant number of code rewrites need to make the delayed
MD> load process as stable as possible.
Probably, current fdemm386 2.06 checks at which stage it loaded
(config.sys or devload at command line), but there is no reasons for this.
MD> Did you think that perhaps it's not so simple since nothing at all in the
MD> DOS world normally manages memory this way?
Don't understand this sentence, but if you mean "why ms-himem and
ms-emm386 are .sys, not .exe". then answer is simple - because loading himem
and emm386 at command line is less useful (DOS process dos=high and dos=umb
only at config.sys). There are no other reasons - and xmsmgr.exe, which
loads XMM at command line, proves this.
But again: I not require immediate implement loading XMS and EMS at
command line, I just say, that there no preventations for this. And I agree
with Eric - checks for 386 (which already present in fdhimem and fdemm386)
should be fixed.
MD> Alternatively, you, Arkady V.Belousov, could add basic configurability to
MD> the kernel code for conditional parsing of CONFIG.SYS.
And how this should be look? Drivers doesn't return errorlevels,
whereas INSTALL= executed after DEVICE=.
MD> It is an idea which
MD> passes the test of rational behavior with an overall increase in OS power
MD> for everyone. Plus, it shouldn't be a terribly difficult feature to
MD> 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
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
