muta...@gmail.com  wrote:   
   > On Friday, July 16, 2021 at 1:32:50 AM UTC+10, anti...@math.uni.wroc.pl   
   wrote:   
   >   
   > > muta...@gmail.com  wrote:   
   > > > What is the reason that drivers for various bits of   
   > > > hardware are being put into the operating system,   
   > > > usually only the very latest version of Windows,   
   > > > instead of being flashed onto the firmware with   
   > > > an API that is available (via BIOS or UEFI) to all   
   > > > operating systems?   
   > >   
   > > There is simple answer: drivers are really part of operating   
   > > system. In more details: driver interface, that is way   
   > > in which drivers interact with operating system is   
   > > important part of design of operating system. DOS   
   > > took CPM design with BIOS interface. This design was   
   > > good for small machines but severly limited possible   
   > > DOS improvements.   
   >   
   > Thanks. Based on your answer, I now have the ability to   
   > refine my question.   
   >   
   > Whenever I pick up some C code, I throw it into a C   
   > compiler to see what it does out-of-the box. I expect   
   > it to be C90-compliant out-of-the-box.   
   >   
   > If you go:   
   >   
   > bcc32 -DGIVE_ME_POSIX *.c   
   >   
   > and it activates a whole lot of Posix functionality that   
   > makes the program so much better, that's fine.   
   >   
   > But the default should be for a non-Posix system,   
   > like MVS 3.8J.   
   >   
   > Same applies to:   
   >   
   > bcc32 -DGIVE_ME_WINDOWS7_AND_ABOVE *.c   
   >   
   > So, if all attached USB sticks are presented by the BIOS   
   > as hard drives by default when the system boots, so that   
   > no USB driver is required, then that's what I want. Or if   
   > not that, then give me a BIOS or UEFI call to access   
   > the USB sticks as hard drives.   
      
   There are much more "USB sticks" than hard drives (mass   
   storage device in USB lingo).  For booting BIOS supports   
   keyboard and probably mouse.  There is some chance that   
   there will be support for USB connected network interfaces.   
   I do not expect support for USB connected digitizing tablet,   
   speakers, camera or microphone.  The same for serial and   
   parallel port or USB printers.  Some USB devices make   
   support tricky: by default they look as drive and driver   
   needs to perform special sequence of commands to switch   
   device to proper operating mode.  The idea above is that   
   fake drive contains Windows drivers and some "autorun"   
   file, when you insert device first time Windows will   
   run autorun file and install the driver.  Once driver   
   is installed it will recognize device, take over it and   
   switch it to normal operating mode.  Such device have   
   no chance to work without special driver, so do not   
   expect support in BIOS.   
      
   > If this is going to produce performance problems, fine,   
   > provide a non-default BIOS/UEFI call to deactivate the   
   > firmware-control over the USB sticks and pass control   
   > to the OS to manage the devices since the OS knows,   
   > or thinks, or is configured, that it has the appropriate   
   > drivers for this device already and can do a better job.   
      
   Note that BIOS traditionaly offered a boot menu and   
   ability to boot from various devices is important for   
   many users.  So BIOS is likely to support typical   
   boot devices.  But there is no reason to put support   
   for non-boot devices in BIOS.  And there is no reason   
   for high-performance ones: even low performance driver   
   should be enough to boot operating system.   
      
   Low cost systems like Raspberry Pi have no of traditional   
   BIOS.  There is mask ROM in CPU (GPU actually in case of   
   Raspberry Pi) which load next stage boot loader from SD   
   card.  Driving SD card is easy, so small mask ROM is   
   enough.  Rest is done via second nad higher level boot   
   loaders loaded from SD card (or other mass storage media).   
   Allwinner procesor use similar tactic, except for that   
   thay load rather large bootloader called U-boot.  U-boot   
   contains drivers for rather large number of devices.   
   IIUC after loading operating system it is still possible   
   to use U-boot drivers.  OTOH U-boot is largish (more than   
   meg in typical configuration) and in a sense more similar   
   to operating system than to normal bootloader.  In a sense   
   using U-boot is similar to using Linux as a BIOS.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)