At 03:01 AM 10/9/2005 +0400, Arkady V.Belousov wrote:
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.
Your last message said that aborting EMM386 and HIMEM 80386-check would be
"much better" and prevent a floodgate of errors. It wouldn't; it has
nothing to do with delayed loading of the memory managers..
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
We were talking about EMM386. There is an explicit reference to EMM386 in
Bernd's message, my reply, your reply, and my reply again.
Which difference in forcing protected mode at config.sys stage of _DOS
session_ and command line stage of DOS session?
It's the difference between forcing virtual 8086 mode on all programs
running under DOS, including already loaded device drivers/TSRs, and
switching into protected mode for a single program to execute. Plus the
rest of the differences I posted.
MD> directly accessing extended memory handles and configuring memory maps,
DOS doesn't access extended memory.
HIMEM and EMM386 set up on a clean memory map. It certainly isn't clean
after loading device drivers of varying allocations, the DOS shell, and
various AUTOEXEC TSRs.
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?
Device drivers don't use UMBs? They don't allocate memory outside of the
DOS memory map? TSRs neither? Sure, if they were all written for 8086
only. Otherwise, you damn betcha they do.
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.
What do you think just loaded all over real and extended memory with
CONFIG.SYS and COMMAND.COM[.EXE] and AUTOEXEC.BAT?
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.
Nonsense. You say XMSMMGR "proves" that HIMEM and EMM386 are only loaded
first for DOS=HIGH and DOS=UMB purposes? There is no logical rigor to that
assertion whatsoever. What it proves is that, under some circumstances
where you don't have conflicting drivers and applications, you can load a
stripped-down extended memory manager at the DOS prompt. That's not a
terribly useful capability for most people.
And how this should be look? Drivers doesn't return errorlevels,
whereas INSTALL= executed after DEVICE=.
Perhaps you could have it conditional on a register return value from an
application, or on device driver name existence. Why does conditional
processing have to depend on errorlevels from existing device drivers which
are written to MS-DOS-only level of awareness?
For my part, I am done arguing whether HIMEM and EMM386 only are needed in
CONFIG.SYS instead of DOS prompt to facilitate DOS=HIGH,UMB handling. I
consider the presence of other major differences self-evident given any
serious attention to the details.
-------------------------------------------------------
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
