From: muta...@gmail.com   
      
   On Wednesday, July 14, 2021 at 8:43:44 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.   
      
   vsyscall. Here is code (posted in this thread) that uses it after obtaining it:   
      
   mov eax,4   
   mov ebx,1   
   mov ecx,msg   
   mov edx,szmsg   
   call [vsyscall]   
      
   > >>> (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"?   
      
   No. The UEFI passes 2 parameters instead. Not sure why   
   2 are required and whether that implies that all environments   
   should ideally be using 2 also.   
      
   > If so, what does it   
   > provide and what will you do in environments which don't provide it?   
      
   I think you're not understanding my proposal.   
      
   First thing is that Linux executables should be built using   
   vsyscall to get the INT 80H out of the executable.   
      
   Once that is done, PDOS-generic can feed the Linux   
   executables with an appropriate vsyscall, and regain   
   control, instead of the executable bypassing PDOS   
   and going to whatever is in the interrupt tables (which   
   I may not have control of if I am running unprivileged).   
      
   So long as everyone follows "the rules" (which I just   
   made up), everything should work.   
      
   Note that I had a similar problem with AmigaOS, and   
   made up a D7 rule.   
      
   As far as I know, PDPCLIB is the only thing that follows   
   the D7 rule, so that means only C programs linked against   
   PDPCLIB will work on BOTH AmigaOS (completely   
   unkludged) AND AmigaPDOS (if it is ever built).   
      
   Basically the non-D7 standard is to hardcode address 4,   
   which AmigaOS has control of, and my D7 standard says   
   that executables should not hardcode 4, but only use the   
   value of 4 if the value is not in D7, and D7 will only be   
   inspected if another well-defined register is 2 GiB or   
   more. Which will only happen if running under AmigaPDOS.   
      
   > > 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.   
      
   What is wrong with a well-known interface called "fwrite"?   
   What possible advantage is there in renaming that to   
   DosWrite() in OS/2 and WriteFile() in Windows?   
      
   Even if there is some advantage in those OSes, what   
   advantage is there in PDOS/386? I more-or-less only   
   support C90-compliant programs.   
      
   I added support for Pascal a week ago, but it uses   
   MSVCRT.DLL too.   
      
   And I added support for Basic a couple of days ago, but   
   it is actually a C program. So also using MSVCRT.DLL.   
      
   > 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.   
      
   I have 3 combinations I wish to eventually support.   
      
   Unprivileged PDOS, unprivileged programs.   
   Privileged PDOS, unprivileged programs.   
   Privileged PDOS, privileged programs.   
      
   Currently only the latter works. Alica came within an ace of   
   replacing 3 with 2. Microsoft assassinated her before she   
   had a chance to fix the bug in her code delta, so I reverted   
   it.   
      
   My main interest is in number 1 though. Which I will   
   run from the Windows command prompt.   
      
   And the S/3X0 version will run under PDOS/3X0 also   
   at the Windows command prompt, under Hercules/380.   
      
   > >> 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.   
      
   I'd rather we went back to manufacturers and asked them   
   to actually fix their bugs.   
      
   > 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.   
      
   I don't know or care about that. I want to get hard disks,   
   floppy disks, and serial ports working, all via the published   
   BIOS interrupts.   
      
   > 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.   
      
   This is what I 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.   
      
   Not sure I understand this correctly, but the BIOS will be   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)