Post by Rod PembertonPost by ***@gmail.comPost by Rod Pembertona) 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.
Post by Rod PembertonThe 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.
Post by Rod PembertonMost 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.
Post by Rod PembertonPost by ***@gmail.comthe 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.
Post by Rod PembertonPost by ***@gmail.comSo 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.
Post by Rod PembertonIf 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.
Post by Rod PembertonE.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.
Post by Rod PembertonPost by ***@gmail.com(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.
Post by Rod PembertonSo, "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.
Post by Rod PembertonSo, "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.
Post by Rod PembertonPost by ***@gmail.comPDOS-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.
Post by Rod PembertonPost by ***@gmail.comPDOS-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.
Post by Rod PembertonI.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
nor cares.
Post by Rod PembertonYour OS should be controlling, programming, and writing
directly to the hardware.
I disagree on "should".
Post by Rod PembertonOtherwise, 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?
Post by Rod Pemberton(*) (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
admirably.
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.
Post by Rod PembertonIn 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:
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/lldos.asm
mov ax, 02401h
int 015h
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.
BFN. Paul.