From: muta...@gmail.com   
      
   On Saturday, July 3, 2021 at 6:03:24 PM UTC+10, James Harris wrote:   
      
   > Then I cannot see the problem. If you produce pdos_write you can have it   
   > invoke whatever OS functions are needed - including invoking code in   
   > your own OS - in whatever ways are needed so there would be no need for   
   > a software interrupt.   
      
   Correct. There is no problem. I was just highlighting the   
   same thing you highlighted with your own code - for   
   some reason both of us ended up with Windows   
   executables that were totally clean, no INT instructions,   
   and both of us ended up with dirty Linux executables,   
   that contain INT instructions.   
      
   Now that I know that it is apparently possible to move   
   the INT instructions out of a Linux executable, I know   
   that Linux can be made clean too.   
      
   I'm not sure your choice of write() is correct though.   
   That is a library function which may be statically linked.   
   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.   
      
   > > (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.   
      
   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.   
      
   In fact, I believe it should simply be a C90 library!   
   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.   
      
   > 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?   
      
   If it is a problem, then I think the proper solution is to   
   buy a computer that can have SeaBIOS flashed, and   
   make any required adjustments to SeaBIOS rather than   
   compensating for manufacturing deficiencies in the   
   OS.   
      
   At least, I think we, and Apple, have this luxury. Microsoft   
   probably needs to compensate for BIOS deficiencies, as   
   the manufacturer is relying on that in some sort of   
   symbiotic relationship. That's just speculation though.   
      
   > Perhaps pdos_write should not include an INT instruction. The call flow   
   > could be   
   >   
   > app --> pdos_write --> write handler   
   >   
   > where the write handler is called, if necessary, by pdos_write in order   
   > to do whatever is needed to effect a write. What it would do would   
   > depend on the facilities of the machine, and you'd have a write handler   
   > for BIOS, a write handler for Windows, a write handler for Linux, a   
   > write handler for Amiga, etc. Then your pdos_write - and hence any app   
   > which uses it - would work on any of them, though you'd need to supply   
   > the different write handlers.   
      
   It is my intention that with the C90-like non-bios I mentioned   
   above, that the non-bios would simply translate a nonbios->printf   
   into an actual printf provided by whatever C compiler/library was   
   being used on some arbitrary host like AmigaOS.   
      
   Note that with AmigaOS in particular there is not any real   
   option of replacing AmigaOS. I have to run PDOS   
   (which will be Amiga-PDOS) under it. There is no problem   
   presenting a C:\ prompt to the user, but the C drive will   
   simply be a flat file up to 2 GiB that is accessed by the   
   standard non-bios Amiga OS C program.   
      
   There is also no problem providing a FAT file system (on   
   that emulated disk), and no problem calling my executables   
   fred.exe or whatever.   
      
   But fred.exe would be an almost-standard AmigaOS C program.   
      
   I say almost-standard because I can only run programs that   
   are aware of the D7 extension that provides an override to   
   address 4. Because AmigaPDOS will not have access to   
   address 4. That is owned by AmigaOS.   
      
   All PDPCLIB-based programs are D7-extension-aware.   
      
   But as usual, currently I believe ONLY PDPCLIB-based   
   programs are D7-extension-aware. :-)   
      
   The D7 extension was thrashed out with people over on   
   an Amiga forum. They weren't particularly impressed, but   
   they did help me select a register and explain why that   
   one was most appropriate for what I was trying to do.   
      
   BTW, it was only over on the Amiga forum where someone   
   explained to me that the BIOS exists to abstract the   
   hardware. And it was only there that I learnt about address   
   4 on the Amiga, and a different way of obtaining OS   
   services. Before that it was always INT/SVC/trap for me.   
      
   I did know about z/OS Unix having pointers in the CVT,   
   but for some reason that didn't have the required impact   
   on me.   
      
   It is the Amiga that got me to come up with PDOS-generic   
   and nearly abandon PDOS/386. I literally did abandon   
   PDOS/386 - I told a Slovakian that he could do whatever   
   he wanted in "src" - I had lost interest in it. But later I   
   realized that there was no harm continuing it until   
   conclusion before refocusing on PDOS-generic.   
      
   PDOS-generic should run under PDOS/3X0 and   
   PDOS/386 (and Windows and Linux) while waiting   
   for a more sophisticated non-bios to be loaded as   
   part of the PDOS/386 boot sequence on real   
   hardware.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)