From: muta...@gmail.com   
      
   On Tuesday, July 6, 2021 at 10:05:21 AM UTC+10, muta...@gmail.com wrote:   
      
   > I'm not concerned about speed on older hardware,   
   > but if it is the cleanest way of removing *all* traces   
   > of "INT 80H" from an executable then I am interested.   
      
   You know what - with a Windows program I can   
   statically-link PDPCLIB so that the only dependency   
   is on kernel32.dll. I currently don't have the equivalent   
   of that in Linux, but the parameter after envp sounds   
   like it will give me that.   
      
   So an alternative to being dependent on libc.   
      
   There's probably not a lot of point in that unless you   
   don't like the fact that libc doesn't interpret "C:\" or   
   open COM1 or something like that, where you need   
   control of the C library.   
      
   So, I'm interested, unless I'm missing something.   
      
   Then there is a separate exercise of replacing libc   
   (the equivalent of msvcrt.dll) itself, as part of   
   having a Linux clone.   
      
   Both sound like equivalents to me, and both are   
   clean.   
      
   Except for the fact that Unix executables put   
   unreasonable demands on the caller. ie the caller   
   needs to be able to manipulate the stack in an   
   unusual way to supply parameters, and a specific   
   weird requirement for malloc() and not sure if   
   system() can be implemented, at least traditionally,   
   without a fork() being present - another weird   
   requirement.   
      
   When I was faced with these issues in PDPCLIB   
   and PDOS, I just said "fuck Unix - Windows, MSDOS,   
   OS/2, AmigaOS (with D7 extension) are much cleaner".   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)