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 replacement? 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 same arguments.

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

Reply via email to