From: james.harris.1@gmail.com   
      
   On 03/07/2021 10:14, muta...@gmail.com wrote:   
   > On Saturday, July 3, 2021 at 6:03:24 PM UTC+10, James Harris wrote:   
      
   ...   
      
   > What is important is whether write() calls __syscall_write()   
   > or whatever that is vectored in from the parameter after   
   > envp rather than doing an INT 80H.   
      
   I don't know what you mean by "the parameter after envp" but it sounds   
   important to your plans.   
      
   >   
   >>> (or probably even better, a UEFI-like   
   >>> library provided at program entry), all is fine.   
   >   
   >> It's best to avoid reliance on both BIOS and UEFI as neither is   
   >> universally available. You will have less dependence on certain hardware   
   >> if you can decouple your OS from both of them.   
   >   
   > You missed my point above. My point was that UEFI   
   > provides a parameter to the executable at startup   
   > rather than using INT instructions like the BIOS, or   
   > Windows-style DLLs.   
      
   Is that what you call "the parameter after envp"? If so, what does it   
   provide and what will you do in environments which don't provide it?   
      
   >   
   > Putting that aside, I agree that a bios-equivalent   
   > layer should exist between the hardware and the   
   > OS and it shouldn't be exactly bios or exactly UEFI.   
      
   OK.   
      
   >   
   > In fact, I believe it should simply be a C90 library!   
      
   I'd have thought there would be a number of layers between C libraries   
   and the hardware.   
      
   > If you're going to have an API anyway, why not make   
   > it use identical function names to C90? There is   
   > still adjustment required because you won't be doing   
   > printf() directly, it would be nonbios->printf() etc.   
   > I have proof of concept of that already in PDOS in   
   > the "bios" directory.   
      
   I'd keep them separate. AISI one needs   
      
      app --> language library --> OS library --> shim --> OS interface   
      
   where the OS library (in your case, clib, AIUI) is shipped with the   
   compiler but is portable; and the OS interface presents a well-known   
   interface for programs to interact with. I see that layer as   
   implementing the OS's 'personality'. Beneath that, there could be any   
   number of layers before one gets to the hardware but apps and the   
   libraries with which they are distributed would be well insulated from   
   the implementation details. That should allow a given program to run on   
   any machine.   
      
   If you wonder why I separated OS library from OS interface it's because   
   they would typically be at different privilege levels. The OS library   
   would typically be user code; the OS interface would typically be in the   
   kernel; and the shim would do whatever's best in a given environment to   
   invoke the privileged-mode code. For your 'use case' where, AIUI, all   
   your 'OS' code is unprivileged they could possibly be combined but if   
   you anticipate ever putting your OS interface in a kernel it's maybe   
   best to ensure apps cannot call such facilities directly now.   
      
   >   
   >> If possible, just use them to get your OS started.   
   >   
   > Ok, I disagree with this. The BIOS/UEFI exists to give   
   > you the hardware independence. I don't think an OS   
   > should directly access the hardware, and I don't think   
   > MSDOS does. So the nonbios layer above should still   
   > call one of bios/uefi.   
   >   
   > Is that a problem?   
      
   It's not a problem if it suits what you want to do. Here are some   
   reasons to avoid it. They may or may not apply to you.   
      
   1. BIOS and UEFI can both have bugs. It would be easier for users to   
   update your software than to update their BIOS or UEFI firmware.   
      
   2. Not all environments provide the same calls as UEFI. For example,   
   BIOSes typically have no NIC support; if you want to drive NICs under a   
   BIOS you'd need to write or obtain drivers for them and integrate them   
   into your OS.   
      
   3. You could end up with your OS largely as an interface to the UEFI   
   standard rather than doing what you believe is best for apps.   
      
   4. When you invoke a ROM routine you have no control as to when it will   
   return. That can cause timing problems for interrupts and, possibly,   
   even directly to users, depending on whether the firmware has a way of   
   returning control to you before it has finished what your syscall to it   
   asked it to do.   
      
   There may be other issues but if you are prepared to live with the   
   dependence and the coercion I can't see why it should not be used.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)