From: james.harris.1@gmail.com   
      
   On 01/07/2021 09:09, muta...@gmail.com wrote:   
   > On Thursday, July 1, 2021 at 4:45:47 PM UTC+10, James Harris wrote:   
   >   
   >> app --> yourcode --> something privileged   
   >>   
   >> then (unless the privileged code will reflect invocations to yourcode)   
   >> those apps could not use software interrupts to get to yourcode but you   
   >> could have libraries which the apps can call. Ideally, the app would say   
   >> something like   
   >>   
   >> pdos_write(chan, "Hello", 5)   
   >>   
   >> where pdos_write would be in a library you've supplied which will, if   
   >> necessary, go on to invoke the relevant routine in yourcode.   
   >>   
   >> Ideally, IMO, pdos_write would be dynamically linked so it would not   
   >> have to be part of the app binary.   
   >   
   > Yes, this is exactly what I want - so long as pdos_write is   
   > in a dynamic library   
      
   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.   
      
    >   
   > (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.   
      
   If possible, just use them to get your OS started.   
      
   >   
   > It's only when pdos_write is statically linked that the   
   > executable suddenly gets an INT hardwired into it,   
   > and suddenly the caller needs to have ensured that   
   > an appropriate interrupt vector exists. Which may   
   > be impossible, because the caller may be an   
   > unprivileged version of PDOS.   
   >   
   >>> Any application that does any interrupt won't work.   
   >>>   
   >>> Win32 executables should work, although I haven't   
   >>> definitively proven that DLLs can be handled.   
   >   
   >> The bottom line is that, AISI, apps should only have to include standard   
   >> calls (no ints, no sysenters etc), and it is the OS or library which   
   >> should supply the code which they call. That's not unusual. I think it's   
   >> how OSes normally make their service routines available.   
   >   
   > Sure, that is not in dispute. It's whether the library is   
   > statically linked and contains an interrupt, or in the case   
   > of AmigaOS, an expectation of address 4 being set to   
   > something special. Or directly manipulating hardware.   
   > Or setting or inspecting segment registers.   
      
   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.   
      
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)