From: muta...@gmail.com   
      
   On Monday, July 5, 2021 at 7:24:11 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?   
      
   As far as I can tell, we're miles from each other.   
      
   First, I have control of a C library. I will plug it in   
   whenever appropriate. I'm not dependent on   
   someone else's decision to call lseek.   
      
   But I do have this in the Linux version of PDPCLIB:   
      
   movl $19, %eax   
   int $0x80   
      
   (ie lseek)   
      
   This is statically-linked in to binaries I produce, which   
   makes them technically unsavory from my point of   
   view because there is an "INT" instruction embedded   
   inside the executable.   
      
   I can handle that in PDOS/386 running on real hardware,   
   but not as an unprivileged PDOS/386 running under   
   Windows.   
      
   If my Linux executables were dependent on an external   
   C library, then PDOS/386 would be able to gain control   
   and handle that, even running under Windows, without   
   any Windows knowledge. Unless it requires an INT 80H   
   to get access to the C library in the first place.   
      
   If my Linux executables are designed to accept a C   
   library, or a routine to get access to a C library, via a   
   pointer after envp, then I have everything I need.   
   PDOS/386 will just feed it something that points   
   right back to PDOS/386.   
      
   I already effectively have this with my Windows   
   executables.   
      
   I don't wish to "trap" anything, because I don't want   
   an INT instruction issued in the first place.   
      
   > 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.   
      
   My OS will be separated from the host OS by what   
   I am calling a "BIOS layer".   
      
   You can see proof of concept here:   
      
   https://sourceforge.net/p/pdos/gitcode/ci/master/tree/bios/bios.c   
      
   That is a bog standard Windows executable, acting   
   as a BIOS. And not just any BIOS, but a C90-like BIOS.   
      
   > 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.   
      
   Ok, currently PDOS/386 directly calls the BIOS,   
   by doing INT 13H instructions, directly linked in   
   to the PDOS.EXE. I wish to change that with   
   PDOS-generic to instead accept a caller (BIOS   
   layer) passing it a pointer. A pointer similar to   
   the one after envp in Linux I'm not familiar with,   
   or similar to the one in UEFI which I have seen.   
      
   If you look at my bios.c above, I used two pointers,   
   but I think one is sufficient.   
      
   With regard to a kernel C library, I currently have   
   functions called PosWriteFile etc that map to   
   MSDOS INT 21H equivalents, but there is no   
   reason for that to be the interface. My plan is for   
   kernel32.dll WriteFile() to instead do a   
   pdos->fwrite() call. ie at every point, things will   
   use the C90 name.   
      
   > > 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.   
      
   Yes, it is *only* dependent on kernel32.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?   
      
   No, that is correct.   
      
   > If so, which C compiler are you calling   
   > "gccwin".   
      
   A fork of GCC 3.2.3 to make it C90-compliant   
   and as a result, work with just PDPCLIB, which,   
   as a result, means it works on both Windows   
   and MVS.   
      
   > E.g., Alexei Frounze's Smaller C? Is it   
   > a port of GCC? Was the compiler called something else   
   > originally? LCC? Cygwin? MinGW? OpenWatcom?   
      
   Nope. It is Joe who is being confusing, by suggesting   
   that gccwin is not related to gcc.   
      
   > > (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.   
      
   I'm pretty sure "encapsulation" is used in computer   
   science. Not sure about decoupling.   
      
   > So, "decoupled" is what you're calling a "freestanding"   
   > or "standalone" OS.   
      
   I'm not sure that is my view.   
      
   I am talking about moving INT instructions out of   
   pdos.exe.   
      
   > 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.   
      
   I don't think I am doing any of those things.   
      
   Currently pdos.c does things like fatWriteFile().   
   I intend to change that to fwrite().   
      
   The flavor of PDPCLIB that is linked in to pdos.c for   
   internal use, will convert that fwrite into a call to   
   fatWriteFile(). It won't be visible in pdos.c.   
      
   > > 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.   
   >   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)