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.
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
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
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
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:
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
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
> 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).
> 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
> 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., <stdio.h>. 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 ...)
Ok, this is all stuff internal to PDPCLIB, and the
msvcrt.dll build of PDPCLIB, or Microsoft's
version of the same thing, but printf() and puts()
will all (in my implementation anyway) devolve into
a call to fwrite() which in turn, at least for PDOS/386,
turns into a call to WriteFile() in kernel32.dll.
> > 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?
Cleanliness is next to Godliness.
> I.e., this indicates dependence upon something, e.g.,
> BIOS file I/O.
From the PDOS-generic point of view, it is beyond scope
what happens after control is passed to the BIOS layer.
It could go up another 57 layers, or it could directly
manipulate the hardware. PDOS-generic neither knows
> Your OS should be controlling, programming, and writing
> directly to the hardware.
I disagree on "should".
> 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. (*)
Surely whoever manages the file system and
memory on behalf of applications is an OS?
Regardless, if you want to call MSDOS and
PDOS/386 - both currently using the BIOS
non-OSes, that's a semantic debate. I'm happy
to call them whatever you want, but
"user-space application" is a bit of an odd term
for PDOS/386 and is likely to confuse people.
What do you call applications that run under
PDOS/386 as currently configured?
> (*) (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.)
The BIOS exists to provide hardware independence
for operating systems and I think it does its job
I didn't actually understand that at the time, but just
had a "feeling" I should stay connected to the BIOS,
even if it meant constantly switching between PM32
and RM16. Now I "know" why that was the exact
right thing to do.
> 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.
It's extremely dependent.
And now that I know that the BIOS even provides an
INT 14H, I'm a very happy camper, because my eyes
light up and I see "SeaBIOS and bluetooth!".
And I had another look at code you provided me too.
I never really liked the look of this bit:
mov ax, 02401h
And I commented it out. But just in the last few days I
realized that this was the only place I actually manipulate
the hardware. I looked up the interrupt number you
provided. And it looks to me like if I use that interrupt,
I will be decoupled from all hardware other than the
CPU. Which sounds like a great place to be. In the same
way that the people who wrote the INT 14H spec had
never even heard of bluetooth.