Michael Devore schreef:
It isn't relevant, as it is overly specific for the example and
ignores the real issue of conditional processing the example is used
for. But if you want an overly specific reply, it won't help that
fdxms286 checks for a 286+-level if a 386-level driver is already loaded.
Again a nice theoretic discussion :) Anyway, are FreeDOS related
programs and drivers also ment to be used on MSDOS or not as partial
If yes, then each driver will have to do the hard work itself, as we
cannot change the MSDOS kernel (including config.sys parsing) even if we
could change the FreeDOS kernel.
By the way, are drivers able to hijack interfaces from each other?
would first loading FDXMS286 and later HIMEM or FDXXMS.SYS gain access
to XMS3.0 and 4GB (overriding FDXMS286 completely) or would these
drivers *always* fail with a simple "XMS driver already loaded" ?
If they all worked I wouldn't need to use one instead of the other for
reliable CD access. Which I do. In mathematical logic terms, that
demonstrates a counterexample which falsifies the original statement.
Yes, it proves that both cdrom drivers are not universal enough. Each of
them works for 99%.
I have no idea what happens if you try to load different drivers with
It is almost impossible that you would fail to see the power of
open-source load control of closed-source drivers at boot time,
however it is implemented, yet you act deliberately obtuse on the
matter. Why, I don't know and don't care, the capability remains a
powerful, flexible, and realistic goal.
There's many possibilities, and not only for CPU checks, but also XMS
(and amount of it), presence of Memdisk arguments, etc.
Without doubt some interested person someday will find time to implement
conditional parsing :)
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