> You cannot simultaneously argue that
> EMM386 may use a 386-level test to help configure loading at boot time, yet
> a separate program cannot legitimately perform the same test. The nature
> of EMM386 and HIMEM precludes loading them at a subsequent DOS prompt.
Hmmm... misunderstanding? I mean: The normal case to load EMM386 is to
use DEVICE=...emm386... - NOT to load it from the prompt. I think we
> Either you can auto-configure at boot based on a 386-level test or you
> cannot. Whether the tests are performed inside or outside a particular
> device driver is irrelevant.
The test already is performed inside the driver, and cannot be performed
in an errorlevel-generating tool. Because errorlevels are not used in
context of DEVICE=... loading. The "autoconfigure" would look like this:
On a 386 or better, things work as intended: Himem loads, then fdxms286
refuses to load because XMS is already present, then emm386 loads, fine.
On a 286, the IDEA would be: Himem refuses to load, as no 386 is present
... then fdxms286 loads. Then emm386 refuses to load, as there is still
no 386 CPU. Would be nice to have that.
The PROBLEM with the idea is: Current emm386 / himem versions FIRST use
386 code and THEN test whether there is a 386 at all. So they just crash
without further message on a 286. Which means that the nice trick for
doing an "universal 286 386 config sys" (I think it was invented by
Bernd?) does not work with the current emm386 / himem. But then again,
those drivers already do contain a 386-cpu-detection. Only at the wrong
place (after first use of 386 specific machine code). Plus the sy3pack
stub contains one LSS (no further 386 specific code). I hope that did
clarify the "smooth abort on 286 wish" and the why of that wish :-).
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