From: noemail@basdxcqvbe.com   
      
   On Sun, 4 Jul 2021 01:26:01 -0700 (PDT)   
   "muta...@gmail.com"  wrote:   
      
   > On Sunday, July 4, 2021 at 4:23:09 PM UTC+10, Rod Pemberton wrote:   
      
   > > a) his OS app -> libc -> host OS functions -> trap & replace   
   >   
   > > Option a) is what Paul is struggling with.   
   >   
   > I'm not 100% sure I understand your summary,   
      
   E.g., if PDOS calls fseek() in the C library, and   
   the C library function calls the OS' function lseek(),   
   then you're attempting to trap and replace lseek() call   
   in the PDOS executable with something that works for your   
   OS, such as a BIOS function or UEFI call.  You have to   
   replace lseek() because it's dependent upon your host   
   OS, e.g., Windows or Linux, and won't work with PDOS.   
   Correct?   
      
   The point is that Option a) is a very low-level place   
   at which to separate your OS from the host OS.  You   
   can separate your code from the host OS code at some   
   other places, which may require less work or which may   
   present a cleaner break point.  Most OS' coded in C   
   seem to write their own kernel C library, with basic   
   functions for text output, file I/O, etc.  They may   
   be built upon the BIOS or they may directly program   
   the hardware, but most OS' directly program the hardware.   
      
   > the apps I am mainly interested in (such as gccwin),   
   > are Win32 programs that are dependent on nothing   
   > more than msvcrt.dll. ie not even kernel32.dll.   
      
   I'm not familiar with M$ C library (msvcrt.dll), but   
   as I stated in another post, most C libraries are   
   usually built up from a handful of OS function calls.   
   I.e., IMO, it's very likely that msvcrt.dll is   
   dependent upon kernel32.dll or some other Windows dll.   
      
   > So I wish to run gccwin under PDOS-generic   
      
   Joe brought up a point about "gccwin" ...   
      
   By "gccwin", I assumed - probably a decade ago - that   
   you were talking about a port of GCC to Windows.  Is   
   that wrong?  If so, which C compiler are you calling   
   "gccwin".  E.g., Alexei Frounze's Smaller C?  Is it   
   a port of GCC?  Was the compiler called something else   
   originally? LCC? Cygwin? MinGW? OpenWatcom?   
      
   > (essentially the same as PDOS/386 but with the   
   > BIOS decoupled and encapsulated in PDPCLIB,   
   > and FAT encapsulated in PDPCLIB).   
      
   "decoupled"   
   "encapsulated"   
      
   Ok.  I didn't expect to see those two words.  I've never   
   heard of them being used in computer programming.  Both   
   are more reminiscent of Electrical Engineering than of   
   Computer Science.   
      
   So, "decoupled" is what you're calling a "freestanding"   
   or "standalone" OS.  So, "decoupling" would be what I   
   was talking about in those four points.  The tools   
   you're using are dependent on the host OS.  You need   
   to decouple them at some point.  I listed 4 methods   
   and places.   
      
   So, "encapsulated" is probably the same as the replacement   
   portion of what I called "trap and replace" of the host   
   OS functions.  You've managed to trap them somehow, and   
   replaced them with alternate functions.  Or, perhaps, you   
   mean that there is a "wrapper" around them, where you modify   
   the BIOS functions to work with PDOS.   
      
   > PDOS-generic will load gccwin etc, and when filling   
   > in all the printf etc function calls (supposedly pointing   
   > to msvcrt.dll) with some sort of callback that doesn't   
   > necessarily even involve any real file called msvcrt.dll.   
      
   Why wouldn't you use sprintf() to memory, and then use your   
   own text display routine directly writing to the hardware,   
   instead of calling printf()? ...   
      
   I.e., C's printf(), *printf() and *scanf() functions are   
   all file I/O dependent, e.g., .  In other words,   
   they'll all attempt to call the host OS' file I/O functions,   
   calls to which you must patch up in your executable or trap   
   at run-time, and then replace with something else suitable   
   for PDOS.   
      
   Also, puts() is much faster, as printf() has a huge routine   
   for formatting strings, but it's likely also file I/O   
   dependent too.  (I didn't check ...)   
      
   > PDOS-generic in turn will not do any actual INT calls   
   > itself, but, very similar to the apps, will simply do   
   > callbacks to the BIOS layer.   
   >   
   > The BIOS layer may or may not be a simple Windows   
   > program written using Borland's C compiler running   
   > under Windows 10 or anything at all really.   
      
   Why do you need the BIOS layer?   
      
   I.e., this indicates dependence upon something, e.g.,   
   BIOS file I/O.   
      
   Your OS should be controlling, programming, and writing   
   directly to the hardware.  Otherwise, it's not really an   
   OS, but a user-space application built upon an OS, e.g.,   
   the BIOS, such as for MS-DOS. (*)   
      
   (*) (I'm not saying there is anything wrong with that,   
   as I use MS-DOS, and I also have an OS-like application,   
   which could be the base for an OS similar to Windows   
   98/SE which starts up from DOS.  But, my OS programs   
   the hardware directly.  My OS is not executing on top   
   or beneath anything else.  No BIOS.)   
      
   In other words, other than E820h or perhaps VESA, I   
   don't understand why you need the BIOS for that much,   
   or why I'm getting the strong impression PDOS is really   
   dependent upon the BIOS, especially for file I/O.   
      
      
   --   
   What is hidden in the ground, when found, is hidden there again?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)