At 11:28 PM 10/10/2005 +0400, Arkady V.Belousov wrote:


     Why to duplicate checks, which already present in himem and emm386?

Why depend on on drivers to unload cleanly if they fail, which they already do not always do in closed-source drivers, despite protestations to the contrary. Why not allow external load control based on any of a thousand conditions the driver was never and could never have been written to consider?

Someday I may also show you a device driver which uses UMBs, disproving the claim that none do.

MD>   ; CHECK286 program returns nonzero if 286-level chip found

     Isn't fdxms286 checks for 286?

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.

MD>   ; ISFLASH program detects USB flash driver presence with nonzero return

     Who will write isflash.sys driver?

Well, let's see, it would be open-source or close-sourced as the author(s) choose. Who will write FreeDOS? Who will write EMM386? Who will write Linux?

Nor need ISFLASH be a SYS driver; a COM or EXE would be fine. COM obviously would be easiest to support.

     Both vide-cdd and oakcdrom are generic IDE drivers and there not need
other drivers, if you already use one of them.

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.

PS: No, I not see there useful examples.

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.

This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more.
Freedos-user mailing list

Reply via email to