microsoft vs linux

193 views
Skip to first unread message

muta...@gmail.com

unread,
Jun 29, 2021, 10:23:02 PMJun 29
to
Win32 executables, at least normal ones, do not have
environmental dependencies like particular segment
registers being set to certain values, or certain interrupt
vectors being set to certain values.

That means that an unprivileged program can set up
the necessary environment to satisfy the Win32
executable.

Linux programs on the other hand do INT 80H calls,
just as MSDOS programs do INT 21H calls. This
means the calling environment needs sufficient
privilege to set up at least one interrupt vector.

Sounds to me like Microsoft has the right approach,
giving maximum flexibility.

Perhaps it would have been EVEN better if Windows
executables accepted the "environment" (callbacks)
via a parameter on the stack, similar to UEFI, and
somewhat similar to AmigaOS, rather than the use of
DLLs.

Any thoughts?

BFN. Paul.

Branimir Maksimovic

unread,
Jun 29, 2021, 10:42:03 PMJun 29
to
On 2021-06-30, muta...@gmail.com <muta...@gmail.com> wrote:
> Win32 executables, at least normal ones, do not have
> environmental dependencies like particular segment
> registers being set to certain values, or certain interrupt
> vectors being set to certain values.
>
> That means that an unprivileged program can set up
> the necessary environment to satisfy the Win32
> executable.
>
> Linux programs on the other hand do INT 80H calls,
> just as MSDOS programs do INT 21H calls. This
> means the calling environment needs sufficient
> privilege to set up at least one interrupt vector.
Linux has vsyscall and int 80h, for 32 bit programs.
one discovers vsyscall address at vector after envp.
OTOH in 64 bit environment it uses syscall instruction
on x86.

>
>
> BFN. Paul.

muta...@gmail.com

unread,
Jun 30, 2021, 12:33:16 AMJun 30
to
On Wednesday, June 30, 2021 at 12:42:03 PM UTC+10, Branimir Maksimovic wrote:

> Linux has vsyscall and int 80h, for 32 bit programs.
> one discovers vsyscall address at vector after envp.

Ok, great, thanks.

> OTOH in 64 bit environment it uses syscall instruction
> on x86.

I didn't understand this. Can you explain please?

Thanks. Paul.

Scott Lurndal

unread,
Jun 30, 2021, 9:22:51 AMJun 30
to
"muta...@gmail.com" <muta...@gmail.com> writes:

>Linux programs on the other hand do INT 80H calls,

No, they don't. Linux doesn't ever use the BIOS for anything.

The SYSCALL or SYSENTER instructions are used on modern x86 processors
by applications (or libraries, e.g. libc) that require services
from the operating system.

Linux hasn't used INT for over a decade.

James Harris

unread,
Jun 30, 2021, 12:19:50 PMJun 30
to
On 30/06/2021 14:22, Scott Lurndal wrote:
> "muta...@gmail.com" <muta...@gmail.com> writes:
>
>> Linux programs on the other hand do INT 80H calls,
>
> No, they don't. Linux doesn't ever use the BIOS for anything.

The Linux int 0x80 call is nothing to do with the BIOS.


--
James Harris

James Harris

unread,
Jun 30, 2021, 12:25:42 PMJun 30
to
On 30/06/2021 03:23, muta...@gmail.com wrote:
> Win32 executables, at least normal ones, do not have
> environmental dependencies like particular segment
> registers being set to certain values, or certain interrupt
> vectors being set to certain values.
>
> That means that an unprivileged program can set up
> the necessary environment to satisfy the Win32
> executable.
>
> Linux programs on the other hand do INT 80H calls,
> just as MSDOS programs do INT 21H calls. This
> means the calling environment needs sufficient
> privilege to set up at least one interrupt vector.

It's not the calling environment which sets up the interrupt vector. The
kernel does that.

As others have said, the Linux kernel can be called in different ways.
Int 0x80 is just one of them. These days sysenter and syscall
instructions are normally used as they are faster. That said, ABI
compatibility is generally maintained so you should be able to call the
Linux kernel with the int if you wish.

It looks as though

https://youtu.be/4CdmGxc5BpU

would explain more.


--
James Harris


muta...@gmail.com

unread,
Jun 30, 2021, 5:48:18 PMJun 30
to
On Thursday, July 1, 2021 at 2:25:42 AM UTC+10, James Harris wrote:

> > Linux programs on the other hand do INT 80H calls,
> > just as MSDOS programs do INT 21H calls. This
> > means the calling environment needs sufficient
> > privilege to set up at least one interrupt vector.

> It's not the calling environment which sets up the interrupt vector. The
> kernel does that.

I wish to run PDOS as an unprivileged kernel. You can
see proof of concept here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/bios/bios.c

Any application that does any interrupt won't work.

Win32 executables should work, although I haven't
definitively proven that DLLs can be handled.

BFN. Paul.

Frank Kotler

unread,
Jun 30, 2021, 7:08:13 PMJun 30
to
On 06/30/2021 09:22 AM, Scott Lurndal wrote:
> "muta...@gmail.com" <muta...@gmail.com> writes:
>
>> Linux programs on the other hand do INT 80H calls,
>
> No, they don't. Linux doesn't ever use the BIOS for anything.

Hi Scott,
I feel really weird disagreeing with you! int 80h us not a BIOS
interrupt. It does still work in 32-bit programs - I use it all the time...

(to Paul)
"syscall" is an instruction... just like "int"...

Best,
Frank



Branimir Maksimovic

unread,
Jun 30, 2021, 8:49:21 PMJun 30
to
On 2021-06-30, muta...@gmail.com <muta...@gmail.com> wrote:
you have syscall instruction on x64_64
>
> Thanks. Paul.

muta...@gmail.com

unread,
Jul 1, 2021, 12:40:40 AMJul 1
to
On Thursday, July 1, 2021 at 9:08:13 AM UTC+10, Frank Kotler wrote:

> (to Paul)
> "syscall" is an instruction... just like "int"...

Ok, thanks. Which means the caller needs to be privileged
enough to set up some table, right?

Something Win32 executables don't need to be able to do.

Does the Linux 80386 parameter after envp require the
caller to have ensured special tables be set up?

Thanks. Paul.

Frank Kotler

unread,
Jul 1, 2021, 1:31:15 AMJul 1
to
On 07/01/2021 12:40 AM, muta...@gmail.com wrote:
> On Thursday, July 1, 2021 at 9:08:13 AM UTC+10, Frank Kotler wrote:
>
>> (to Paul)
>> "syscall" is an instruction... just like "int"...
>
> Ok, thanks. Which means the caller needs to be privileged
> enough to set up some table, right?

No... I don't think so.

> Something Win32 executables don't need to be able to do.
>
> Does the Linux 80386 parameter after envp require the
> caller to have ensured special tables be set up?

No, I don't think so.

I'm not sure, Paul, but I think your original premise may not be
correct. I do not think that Windows makes it any "easier" for an
executable than Linux. I haven't run Windows since win98, so I may not
be up-to-date... Does fs not point to "thread local storage"? (a
non-flat descriptor)? Does not Windows use an interrupt... int 0xE2 ???
" behind the scenes"?

I'm not certain, but I think you may be off-base here... interesting
question, in any case.

Best,
Frank

James Harris

unread,
Jul 1, 2021, 2:45:47 AMJul 1
to
On 30/06/2021 22:48, muta...@gmail.com wrote:
> On Thursday, July 1, 2021 at 2:25:42 AM UTC+10, James Harris wrote:
>
>>> Linux programs on the other hand do INT 80H calls,
>>> just as MSDOS programs do INT 21H calls. This
>>> means the calling environment needs sufficient
>>> privilege to set up at least one interrupt vector.
>
>> It's not the calling environment which sets up the interrupt vector. The
>> kernel does that.
>
> I wish to run PDOS as an unprivileged kernel. You can
> see proof of concept here:
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/bios/bios.c

I am not sure what's happening in that - and I've not been following the
details of what you are doing - but in principle if you have the calling
sequence as

app --> yourcode --> something privileged

then (unless the privileged code will reflect invocations to yourcode)
those apps could not use software interrupts to get to yourcode but you
could have libraries which the apps can call. Ideally, the app would say
something like

pdos_write(chan, "Hello", 5)

where pdos_write would be in a library you've supplied which will, if
necessary, go on to invoke the relevant routine in yourcode.

Ideally, IMO, pdos_write would be dynamically linked so it would not
have to be part of the app binary.

>
> Any application that does any interrupt won't work.
>
> Win32 executables should work, although I haven't
> definitively proven that DLLs can be handled.

The bottom line is that, AISI, apps should only have to include standard
calls (no ints, no sysenters etc), and it is the OS or library which
should supply the code which they call. That's not unusual. I think it's
how OSes normally make their service routines available.


--
James Harris

muta...@gmail.com

unread,
Jul 1, 2021, 4:03:27 AMJul 1
to
On Thursday, July 1, 2021 at 3:31:15 PM UTC+10, Frank Kotler wrote:

> I'm not sure, Paul, but I think your original premise may not be
> correct. I do not think that Windows makes it any "easier" for an

Maybe my premise needs to be refined. Let's start with
a non-multitasking "hello world" program. Everything I
write is a glorified "hello world" (C90-compliant).

> executable than Linux. I haven't run Windows since win98, so I may not
> be up-to-date... Does fs not point to "thread local storage"? (a
> non-flat descriptor)?

It may be, but I am certain there is no manipulation or use
of "fs" in the Win32 executables I produce, because I know
what goes into every byte of code, which is how I know it
is all public domain, so my executables are totally public
domain.

> Does not Windows use an interrupt... int 0xE2 ???
> " behind the scenes"?

I don't care if there are 50 billion INT calls and syscalls
and manipulation of hardware and segment register
manipulation so long as it happens OUTSIDE my
executable.

At least when I'm wearing my application programmer's hat,
which I am at the moment, looking for clean executables.

BFN. Paul.

muta...@gmail.com

unread,
Jul 1, 2021, 4:09:39 AMJul 1
to
On Thursday, July 1, 2021 at 4:45:47 PM UTC+10, James Harris wrote:

> app --> yourcode --> something privileged
>
> then (unless the privileged code will reflect invocations to yourcode)
> those apps could not use software interrupts to get to yourcode but you
> could have libraries which the apps can call. Ideally, the app would say
> something like
>
> pdos_write(chan, "Hello", 5)
>
> where pdos_write would be in a library you've supplied which will, if
> necessary, go on to invoke the relevant routine in yourcode.
>
> Ideally, IMO, pdos_write would be dynamically linked so it would not
> have to be part of the app binary.

Yes, this is exactly what I want - so long as pdos_write is
in a dynamic library (or probably even better, a UEFI-like
library provided at program entry), all is fine.

It's only when pdos_write is statically linked that the
executable suddenly gets an INT hardwired into it,
and suddenly the caller needs to have ensured that
an appropriate interrupt vector exists. Which may
be impossible, because the caller may be an
unprivileged version of PDOS.

> > Any application that does any interrupt won't work.
> >
> > Win32 executables should work, although I haven't
> > definitively proven that DLLs can be handled.

> The bottom line is that, AISI, apps should only have to include standard
> calls (no ints, no sysenters etc), and it is the OS or library which
> should supply the code which they call. That's not unusual. I think it's
> how OSes normally make their service routines available.

Sure, that is not in dispute. It's whether the library is
statically linked and contains an interrupt, or in the case
of AmigaOS, an expectation of address 4 being set to
something special. Or directly manipulating hardware.
Or setting or inspecting segment registers.

BFN. Paul.

Rod Pemberton

unread,
Jul 1, 2021, 4:45:25 AMJul 1
to
On Wed, 30 Jun 2021 17:25:39 +0100
James Harris <james.h...@gmail.com> wrote:

> On 30/06/2021 03:23, muta...@gmail.com wrote:

> > Win32 executables, at least normal ones, do not have
> > environmental dependencies like particular segment
> > registers being set to certain values, or certain interrupt
> > vectors being set to certain values.
> >
> > That means that an unprivileged program can set up
> > the necessary environment to satisfy the Win32
> > executable.
> >
> > Linux programs on the other hand do INT 80H calls,
> > just as MSDOS programs do INT 21H calls. This
> > means the calling environment needs sufficient
> > privilege to set up at least one interrupt vector.
>
> It's not the calling environment which sets up the interrupt vector.
> The kernel does that.
>

I think that misses his point ...

He'd rather have function calls instead of interrupts. I.e., he can
simulate the OS functions easier especially since he doesn't need
privilege to set up an interrupt table.

--
What is hidden in the ground, when found, is hidden there again?

Rod Pemberton

unread,
Jul 1, 2021, 4:45:29 AMJul 1
to
If the OS provided the OS API via function calls instead of interrupts,
then he could possibly call them directly, depending on OS privileges,
and if desired, he could definitely emulate them. Interrupts act as a
barrier to those functions as privilege is required to set up an
interrupt table, or or OS control is required.

So, with a Win32 executable, he suspects he call provide the OS
functions, if they're unavailable for his host environment, since a
Win32 executable apparently calls functions directly instead of using
software interrupts.

Rod Pemberton

unread,
Jul 1, 2021, 4:46:23 AMJul 1
to
On Thu, 1 Jul 2021 01:21:05 -0400
Frank Kotler <fbko...@myfairpoint.net> wrote:

> On 07/01/2021 12:40 AM, muta...@gmail.com wrote:
> > On Thursday, July 1, 2021 at 9:08:13 AM UTC+10, Frank Kotler wrote:

> >> (to Paul)
> >> "syscall" is an instruction... just like "int"...
> >
> > Ok, thanks. Which means the caller needs to be privileged
> > enough to set up some table, right?
>
> No... I don't think so.
>

For x86, LIDT, LGDT are unprivileged instructions only in real-mode.
LIDT, LGDT are privileged instructions in protected-mode. You must be
in Ring-0 to use LIDT, LGDT in protected-mode.

I.e., if you're executing under Windows or Linux etc, then, "Yes" you
need privilege to set up an interrupt table via LIDT. In other words,
you can't set up your own interrupt table if you "wish to run PDOS as an
unprivileged kernel" under Linux or Windows etc.

Rod Pemberton

unread,
Jul 1, 2021, 4:49:56 AMJul 1
to
... he suspects he can call the provided OS ...

Rod Pemberton

unread,
Jul 1, 2021, 4:52:12 AMJul 1
to
On Thu, 1 Jul 2021 04:47:43 -0500
Rod Pemberton <noe...@basdxcqvbe.com> wrote:

> On Thu, 1 Jul 2021 01:21:05 -0400
> Frank Kotler <fbko...@myfairpoint.net> wrote:
> > On 07/01/2021 12:40 AM, muta...@gmail.com wrote:
> > > On Thursday, July 1, 2021 at 9:08:13 AM UTC+10, Frank Kotler
> > > wrote:

> > >> (to Paul)
> > >> "syscall" is an instruction... just like "int"...
> > >
> > > Ok, thanks. Which means the caller needs to be privileged
> > > enough to set up some table, right?
> >
> > No... I don't think so.
> >
>
> For x86, LIDT, LGDT are unprivileged instructions only in real-mode.
> LIDT, LGDT are privileged instructions in protected-mode. You must be
> in Ring-0 to use LIDT, LGDT in protected-mode.
>

...

> I.e., if you're executing under Windows or Linux etc, then, "Yes" you
> need privilege to set up an interrupt table via LIDT. In other words,
> you can't set up your own interrupt table if you "wish to run PDOS as
> an unprivileged kernel" under Linux or Windows etc.
>

Replied to Frank but was talking to Paul here. Sorry.

Branimir Maksimovic

unread,
Jul 1, 2021, 4:54:14 AMJul 1
to
On 2021-07-01, muta...@gmail.com <muta...@gmail.com> wrote:
> On Thursday, July 1, 2021 at 9:08:13 AM UTC+10, Frank Kotler wrote:
>
>> (to Paul)
>> "syscall" is an instruction... just like "int"...
>
> Ok, thanks. Which means the caller needs to be privileged
> enough to set up some table, right?
Nope, no privileges needed.

>
> Something Win32 executables don't need to be able to do.
>
> Does the Linux 80386 parameter after envp require the
> caller to have ensured special tables be set up?

no.
>
> Thanks. Paul.

anti...@math.uni.wroc.pl

unread,
Jul 1, 2021, 8:46:29 AMJul 1
to
muta...@gmail.com <muta...@gmail.com> wrote:
> Win32 executables, at least normal ones, do not have
> environmental dependencies like particular segment
> registers being set to certain values, or certain interrupt
> vectors being set to certain values.
>
> That means that an unprivileged program can set up
> the necessary environment to satisfy the Win32
> executable.
>
> Linux programs on the other hand do INT 80H calls,
> just as MSDOS programs do INT 21H calls. This
> means the calling environment needs sufficient
> privilege to set up at least one interrupt vector.

No. First, both Linux and Windows programs do system
calls. In Linux system call may be INT 80H (it was
in original i386 Linux) but can be done differently.
Whatever way system calls are done, in normal
operation of system they cause transition of priviledge
and setting receiver of system call frequently require
priviledge. No Linux there is unpriviledged mechanizm
to intercept system calls. There was so called "user level
Linux kernel", which was version of Linux kernel running
in user space, which used interception mechanizm to
receive system calls. This kernel needed privilege
(root right) to perform privileged operations on
behalf of programs, but interception is availble
to ordinary users. In moderm times this approach
is obsoleted by "virtualization extentions" present
in modern processors.

Concerning Windows, my impression was that there was
no comparable mechanizem on Windows. AFAICS main
difference was that much of system call interface
of Windows was undocumented and many Windows
programmers were unaware that it exist at all.
OTOH there is a lot of info about Linux systems
calls.

You later wrote that you are interested in C90
programs. "Well behaved" C90 program is supposed
to use library functions and to dynamically link
to C library, both on Windows and Linux. On Linux
setting environment so that program uses your C
library instead of provided one require some effort
(there are several details that need to be done)
but is entirely unprivileged operation.

One more thing: on modern systems when program does
INT 80H (or say INT 21H) what happens is general
protection fault. So it is enough to set up exactly
one interrupt vector, namly the one which handles
general protection fault. But this handler must
handle a lot of things, which slows down handling
of system calls, so there is tendency to avoid
using INT instruction as system call interface.
However, if you want to stick to old ways and
use INT, that what you really want is that
system general protection fault handler recognizes
INT instruction and passes control to your program.
In Linux for INT 21H this is easy, because INT 21H
is treated as illegal instruction and system calls
appropriate signal handler in your program (if you
do not set up a hander your program would crash).
With INT 80H it is a bit more complicated, as
normally Linux fault handler would treat it as
system call. But you can use system call interception
to handle system calls in your code.

--
Waldek Hebisch

Scott Lurndal

unread,
Jul 1, 2021, 2:22:46 PMJul 1
to
Frank Kotler <fbko...@myfairpoint.net> writes:
>On 06/30/2021 09:22 AM, Scott Lurndal wrote:
>> "muta...@gmail.com" <muta...@gmail.com> writes:
>>
>>> Linux programs on the other hand do INT 80H calls,
>>
>> No, they don't. Linux doesn't ever use the BIOS for anything.
>
>Hi Scott,
>I feel really weird disagreeing with you! int 80h us not a BIOS
>interrupt. It does still work in 32-bit programs - I use it all the time...

Good point, It's been over a decade since I used any 32-bit linux system
or application.

Frank Kotler

unread,
Jul 2, 2021, 12:42:32 AMJul 2
to
On 07/01/2021 04:03 AM, muta...@gmail.com wrote:
...
> It may be, but I am certain there is no manipulation or use
> of "fs" in the Win32 executables I produce, because I know
> what goes into every byte of code,

Excellent!
...
> I don't care if there are 50 billion INT calls and syscalls
> and manipulation of hardware and segment register
> manipulation so long as it happens OUTSIDE my
> executable.

Okay. I can assure you that there is no "crap" in an ordinary Linux
executable. The int 80h vector, ect. are set up by the OS. well outside
of out executable. No special permissions.

We can discuss it further, but I don't think we need to...

I don't usually post here, but sometimes read the group.. "Hi" to all my
friends...

Best,
Frank

muta...@gmail.com

unread,
Jul 2, 2021, 2:14:27 AMJul 2
to
On Friday, July 2, 2021 at 2:42:32 PM UTC+10, Frank Kotler wrote:

> > It may be, but I am certain there is no manipulation or use
> > of "fs" in the Win32 executables I produce, because I know
> > what goes into every byte of code,
> Excellent!
> ...
> > I don't care if there are 50 billion INT calls and syscalls
> > and manipulation of hardware and segment register
> > manipulation so long as it happens OUTSIDE my
> > executable.

> Okay. I can assure you that there is no "crap" in an ordinary Linux
> executable. The int 80h vector, ect. are set up by the OS. well outside
> of out executable. No special permissions.

No, you don't get my point. "int 80h" inside my executable
*is* "crap". It requires the *caller* to have special
permissions (they need to ensure an interrupt vector
table exists).

It may not exist.

I want to run Linux executables from PDOS/386, running
as an unprivileged program running under Windows 10.
I don't have access to INT 80H so the executable will
fail (unless I was to somehow scan the executable and
zap them all into callbacks).

Whereas if I run Windows executables from PDOS/386,
running as an unprivileged program running under Linux,
I do not have this problem. Because the Win32 executables
(at least mine) that follow the kernel32/msvcrt rules, have
address stubs that are filled in at load time.

I can easily get PDOS/386 to load the Win32 executable,
redirect those stubs to myself, and it doesn't matter that
there is no kernel32, no msvcrt, no Windows, and Linux
has no clue whatsoever about anything that is happening.
No interrupt table is involved either, although PDOS/386
will (nominally *) call INT 80H to get access to Linux services.

BFN. Paul.


(*) Then we get to making PDOS clean by offloading BIOS
calls to another abstraction layer, and then it is only at
the BIOS level that INT 80H is (nominally **) done.


(**) Then we get to the next abstraction layer where the
BIOS is implemented by calling the functions provided
by the parameter after envp, rather than mandating an
interrupt table. Then Linux itself can be running
unauthorized, under perhaps MacOS.

Rod Pemberton

unread,
Jul 2, 2021, 5:04:46 AMJul 2
to
On Thu, 1 Jul 2021 12:46:26 +0000 (UTC)
anti...@math.uni.wroc.pl wrote:

> muta...@gmail.com <muta...@gmail.com> wrote:

> > [...]
>
> You later wrote that you are interested in C90
> programs. "Well behaved" C90 program is supposed
> to use library functions and to dynamically link
> to C library, both on Windows and Linux.

I disagree.

There is no need for a "well behaved" C90 program to use C library
functions, as many C library functions are "well behaved", especially
those that are not host dependent, because the C library functions only
use the C language proper. Therefore, you can conclude that any C90
program, even if it doesn't use the C library, is "well behaved", since
the library is built upon the C language proper, and the language is
"well behaved". It's only when operating underneath an operating
system (OS) which implements host specific behaviors and OS specific
behaviors, that a C90 program needs to call the OS specific C library
to become "well behaved" with the OS.

Rod Pemberton

unread,
Jul 2, 2021, 5:05:55 AMJul 2
to
On Thu, 1 Jul 2021 23:14:26 -0700 (PDT)
"muta...@gmail.com" <muta...@gmail.com> wrote:

> On Friday, July 2, 2021 at 2:42:32 PM UTC+10, Frank Kotler wrote:
>
> > > It may be, but I am certain there is no manipulation or use
> > > of "fs" in the Win32 executables I produce, because I know
> > > what goes into every byte of code,
> > Excellent!
> > ...
> > > I don't care if there are 50 billion INT calls and syscalls
> > > and manipulation of hardware and segment register
> > > manipulation so long as it happens OUTSIDE my
> > > executable.
>
> > Okay. I can assure you that there is no "crap" in an ordinary Linux
> > executable. The int 80h vector, ect. are set up by the OS. well
> > outside of out executable. No special permissions.
>
> No, you don't get my point. "int 80h" inside my executable
> *is* "crap". It requires the *caller* to have special
> permissions (they need to ensure an interrupt vector
> table exists).
>
> It may not exist.

...

> I want to run Linux executables from PDOS/386, running
> as an unprivileged program running under Windows 10.
> I don't have access to INT 80H so the executable will
> fail (unless I was to somehow scan the executable and
> zap them all into callbacks).
>

You may wish to look at this old project. It directly runs Linux
executables under Windows. An old post of mine says it has an "int
0x80 syscall interface, DLL loader, and no POSIX layer".

LINE is not an emulator
https://sourceforge.net/projects/line/

muta...@gmail.com

unread,
Jul 2, 2021, 6:15:36 AMJul 2
to
On Friday, July 2, 2021 at 7:05:55 PM UTC+10, Rod Pemberton wrote:

> > I want to run Linux executables from PDOS/386, running
> > as an unprivileged program running under Windows 10.
> > I don't have access to INT 80H so the executable will
> > fail (unless I was to somehow scan the executable and
> > zap them all into callbacks).

Note that that "desire" was for illustration purposes only.
I couldn't give a shit about crap like Linux.

What interests me is Win32-like S/370 executables
running under PDOS-generic (using FAT) running
under the current PDOS/3X0 (using CKD).

With all executables running at native speed on real
S/3X0 hardware.

That's largely embryonic. I'm not 100% sure what a
Win32-like S/370 executable is, and I don't have a
linker to produce the theoretical executable.

There is a S/370 assembler and linker written in
Python, about 30,000 lines, and I've made an attempt
at turning Python 3.3 into a C90-compliant executable,
a pre-requisite to working on either PDOS/386 or
PDOS/3X0. I have an executable built, but it produces
an internal error, likely due to one of the shortcuts I
took to get a build at all.

Someone else on the mainframe interested in Python
said he would take a look, and then went quiet.

I have a lot of paths open at any one time. But some
of them do indeed close. I have a Windows C compiler
with source (gccwin, 3.2.3) not dependent on Cygwin
crap, buildable from source. And in fact, the only
compiler that has been ported to PDOS/386. It only
became available in a form that passed my integrity
checks about 23 hours and 15 minutes ago, with a
lot of updates to pdos.org during the process.

There is method to the madness. Or there is madness.
Take your pick.

> You may wish to look at this old project. It directly runs Linux
> executables under Windows. An old post of mine says it has an "int
> 0x80 syscall interface, DLL loader, and no POSIX layer".
>
> LINE is not an emulator
> https://sourceforge.net/projects/line/

I checked out the link and stopped here:

LINE Is Not an Emulator. LINE executes unmodified Linux applications on Windows by intercepting Linux system calls.


Intercepting Linux system calls, presumably by inserting
something into the INT 80H vector, requires privilege, the
thing I was illustrating I wanted to avoid.

BFN. Paul.

Scott Lurndal

unread,
Jul 2, 2021, 11:42:51 AMJul 2
to
"muta...@gmail.com" <muta...@gmail.com> writes:
>On Friday, July 2, 2021 at 7:05:55 PM UTC+10, Rod Pemberton wrote:
>
>> > I want to run Linux executables from PDOS/386, running
>> > as an unprivileged program running under Windows 10.
>> > I don't have access to INT 80H so the executable will
>> > fail (unless I was to somehow scan the executable and
>> > zap them all into callbacks).
>
>Note that that "desire" was for illustration purposes only.
>I couldn't give a shit about crap like Linux.

And the rest of us don't give a shit about useless crap like PDOS,
FAT, BIOS or S/370.

Rod Pemberton

unread,
Jul 2, 2021, 8:42:25 PMJul 2
to
Look, I'm not entirely sure of the mechanism, but I think LINE is a
user space app, i.e., it wouldn't have the necessary privilege to
intercept INT 80H. Hence, I thought it might be worth a look at their
technique. Maybe, Windows has some function that is being used.

muta...@gmail.com

unread,
Jul 2, 2021, 9:07:18 PMJul 2
to
On Saturday, July 3, 2021 at 10:42:25 AM UTC+10, Rod Pemberton wrote:

> Look, I'm not entirely sure of the mechanism, but I think LINE is a
> user space app, i.e., it wouldn't have the necessary privilege to
> intercept INT 80H. Hence, I thought it might be worth a look at their
> technique. Maybe, Windows has some function that is being used.

Ok, good point. If Windows is willing to (at its whim) allow
an app to set INT 80H, then that would indeed work.

PDOS/386 also allows apps to trash interrupt vectors.

But ideally, an executable should not be relying on the grace
of the calling environment to give it access to an interrupt
(and there may be conflicts with interrupt numbers too).

It is better if the executable just quietly executes callbacks,
in one form or another, so that no-one with any authority
has any idea whatsoever what is happening.

THAT is my definition of a "clean executable", and Win32
console mode programs, at least the ones I produce, fit
that description, even though they are not *necessarily*
my preferred design.

Rumor has it that Linux supports the same thing via the
parameter after envp, which is great, and *possibly* even
superior to Win32, so I'll put that on my "to do" list for
changes to PDPCLIB to remove the INT 80H in the Linux target.

BFN. Paul.

Rod Pemberton

unread,
Jul 2, 2021, 9:25:24 PMJul 2
to
Honestly, I don't think that Paul's comments were intended to be as
harsh as you've apparently been taking them. He's downunder.

> And the rest of us don't give a shit about useless crap like PDOS,
> FAT, BIOS or S/370.

So, Scott, are you working on your own OS? I apparently missed
your mention of it. So, what are you planning to do? You're here for
a good reason, right?


Personally, I'm in the world of EXT4 and BIOS and 64-bit (Linux).
Although, I'm still in the world of FAT and BIOS and 32-bit (MS-DOS).
No UEFI, yet though, which will be a total mess if there is no BIOS
support anymore via CSM. I'd doubt that most others here have moved to
UEFI, as you're about the only one who mentions it. As for S/370, I
have no idea what that is, other than it's IBM. As for PDOS, I know
it's a DOS-like OS that Paul has been working on for a long time,
off-and-on again. Nothing wrong with that, IMO. It's a personal and
intellectual challenge. Other people have golf.


I do understand your perspective. Tool did say in their song A-Enema
(AEnema), "Yeah, f--k retro anything," ... as well as wishing that the
"hopeless f--king hole" called Los Angeles would be flushed out (via an
implicit enema) into the Arizona Bay (the sea water offshore of Arizona
once California sinks) via an AEnima (with 'i' not 'e') event which is
an apocalyptic event of sinking underwater like Atlantis, and also the
name of their album.


We - the rest of us, the 49% of America not dumb enough to put an
incompetent vegetable and radical Muslim terrorist into the White House
- can solidly say the same, "flush it all away", but about the whole of
California, and it's radically politically biased socialist government
and it's overbearing paternalistic censorial suppressive tech
companies, can't we? They don't represent America or it's values, just
a very, very limited subset of American values, but act as if everyone
else should obey them and their misguided beliefs ... Bigots.

James Harris

unread,
Jul 3, 2021, 4:03:24 AMJul 3
to
On 01/07/2021 09:09, muta...@gmail.com wrote:
> On Thursday, July 1, 2021 at 4:45:47 PM UTC+10, James Harris wrote:
>
>> app --> yourcode --> something privileged
>>
>> then (unless the privileged code will reflect invocations to yourcode)
>> those apps could not use software interrupts to get to yourcode but you
>> could have libraries which the apps can call. Ideally, the app would say
>> something like
>>
>> pdos_write(chan, "Hello", 5)
>>
>> where pdos_write would be in a library you've supplied which will, if
>> necessary, go on to invoke the relevant routine in yourcode.
>>
>> Ideally, IMO, pdos_write would be dynamically linked so it would not
>> have to be part of the app binary.
>
> Yes, this is exactly what I want - so long as pdos_write is
> in a dynamic library

Then I cannot see the problem. If you produce pdos_write you can have it
invoke whatever OS functions are needed - including invoking code in
your own OS - in whatever ways are needed so there would be no need for
a software interrupt.

>
> (or probably even better, a UEFI-like
> library provided at program entry), all is fine.

It's best to avoid reliance on both BIOS and UEFI as neither is
universally available. You will have less dependence on certain hardware
if you can decouple your OS from both of them.

If possible, just use them to get your OS started.

>
> It's only when pdos_write is statically linked that the
> executable suddenly gets an INT hardwired into it,
> and suddenly the caller needs to have ensured that
> an appropriate interrupt vector exists. Which may
> be impossible, because the caller may be an
> unprivileged version of PDOS.
>
>>> Any application that does any interrupt won't work.
>>>
>>> Win32 executables should work, although I haven't
>>> definitively proven that DLLs can be handled.
>
>> The bottom line is that, AISI, apps should only have to include standard
>> calls (no ints, no sysenters etc), and it is the OS or library which
>> should supply the code which they call. That's not unusual. I think it's
>> how OSes normally make their service routines available.
>
> Sure, that is not in dispute. It's whether the library is
> statically linked and contains an interrupt, or in the case
> of AmigaOS, an expectation of address 4 being set to
> something special. Or directly manipulating hardware.
> Or setting or inspecting segment registers.

Perhaps pdos_write should not include an INT instruction. The call flow
could be

app --> pdos_write --> write handler

where the write handler is called, if necessary, by pdos_write in order
to do whatever is needed to effect a write. What it would do would
depend on the facilities of the machine, and you'd have a write handler
for BIOS, a write handler for Windows, a write handler for Linux, a
write handler for Amiga, etc. Then your pdos_write - and hence any app
which uses it - would work on any of them, though you'd need to supply
the different write handlers.



--
James Harris

James Harris

unread,
Jul 3, 2021, 4:23:44 AMJul 3
to
On 01/07/2021 10:46, Rod Pemberton wrote:
> On Thu, 1 Jul 2021 07:45:45 +0100
> James Harris <james.h...@gmail.com> wrote:
>
>> On 30/06/2021 22:48, muta...@gmail.com wrote:
>>> On Thursday, July 1, 2021 at 2:25:42 AM UTC+10, James Harris wrote:
>
>>> Any application that does any interrupt won't work.
>>>
>>> Win32 executables should work, although I haven't
>>> definitively proven that DLLs can be handled.
>>
>> The bottom line is that, AISI, apps should only have to include
>> standard calls (no ints, no sysenters etc), and it is the OS or
>> library which should supply the code which they call. That's not
>> unusual. I think it's how OSes normally make their service routines
>> available.
>>
>
> If the OS provided the OS API via function calls instead of interrupts,
> then he could possibly call them directly, depending on OS privileges,
> and if desired, he could definitely emulate them. Interrupts act as a
> barrier to those functions as privilege is required to set up an
> interrupt table, or or OS control is required.

You and I may be of the same opinion on this. I've not been following
everything that Paul is trying to do but ISTM sensible for an OS to
provide functions for an app to call to invoke any the OS's services.
Then those functions can invoke the OS proper in whatever way is needed.

In addition, I'd personally prefer such functions to be linked
dynamically so that the application binary will work in different
environments.

>
> So, with a Win32 executable, he suspects he call provide the OS
> functions, if they're unavailable for his host environment, since a
> Win32 executable apparently calls functions directly instead of using
> software interrupts.
>

I was a bit puzzled by that but then I looked back at some primer code I
wrote years ago when I was trying to find out how to call Linux and
Windows. Whatever I based the code on did, indeed, recommend calling
Linux using an INT instruction.

Here's the Linux code and you can see the INT call within it.

http://codejar.pldev.org/aen/linux_stdout.nasm

By contrast, here's the Windows code and you can see that it invokes the
OS using a normal call instruction.

http://codejar.pldev.org/aen/windows_stdout.nasm

The latter code takes a better approach. It is more flexible, leaves the
app binary holding only app code, and means that the app can invoke OS
functions simply with normal function calls.

As a bonus it even specifies which DLL to get each entry point from.

That said, if I was writing the Linux code now I would look into how to
invoke the write system call via the write syscall function

https://man7.org/linux/man-pages/man2/write.2.html

and how to get it to be pulled in by dynamic linking.



--
James Harris

muta...@gmail.com

unread,
Jul 3, 2021, 5:14:59 AMJul 3
to
On Saturday, July 3, 2021 at 6:03:24 PM UTC+10, James Harris wrote:

> Then I cannot see the problem. If you produce pdos_write you can have it
> invoke whatever OS functions are needed - including invoking code in
> your own OS - in whatever ways are needed so there would be no need for
> a software interrupt.

Correct. There is no problem. I was just highlighting the
same thing you highlighted with your own code - for
some reason both of us ended up with Windows
executables that were totally clean, no INT instructions,
and both of us ended up with dirty Linux executables,
that contain INT instructions.

Now that I know that it is apparently possible to move
the INT instructions out of a Linux executable, I know
that Linux can be made clean too.

I'm not sure your choice of write() is correct though.
That is a library function which may be statically linked.
What is important is whether write() calls __syscall_write()
or whatever that is vectored in from the parameter after
envp rather than doing an INT 80H.

> > (or probably even better, a UEFI-like
> > library provided at program entry), all is fine.

> It's best to avoid reliance on both BIOS and UEFI as neither is
> universally available. You will have less dependence on certain hardware
> if you can decouple your OS from both of them.

You missed my point above. My point was that UEFI
provides a parameter to the executable at startup
rather than using INT instructions like the BIOS, or
Windows-style DLLs.

Putting that aside, I agree that a bios-equivalent
layer should exist between the hardware and the
OS and it shouldn't be exactly bios or exactly UEFI.

In fact, I believe it should simply be a C90 library!
If you're going to have an API anyway, why not make
it use identical function names to C90? There is
still adjustment required because you won't be doing
printf() directly, it would be nonbios->printf() etc.
I have proof of concept of that already in PDOS in
the "bios" directory.

> If possible, just use them to get your OS started.

Ok, I disagree with this. The BIOS/UEFI exists to give
you the hardware independence. I don't think an OS
should directly access the hardware, and I don't think
MSDOS does. So the nonbios layer above should still
call one of bios/uefi.

Is that a problem?

If it is a problem, then I think the proper solution is to
buy a computer that can have SeaBIOS flashed, and
make any required adjustments to SeaBIOS rather than
compensating for manufacturing deficiencies in the
OS.

At least, I think we, and Apple, have this luxury. Microsoft
probably needs to compensate for BIOS deficiencies, as
the manufacturer is relying on that in some sort of
symbiotic relationship. That's just speculation though.

> Perhaps pdos_write should not include an INT instruction. The call flow
> could be
>
> app --> pdos_write --> write handler
>
> where the write handler is called, if necessary, by pdos_write in order
> to do whatever is needed to effect a write. What it would do would
> depend on the facilities of the machine, and you'd have a write handler
> for BIOS, a write handler for Windows, a write handler for Linux, a
> write handler for Amiga, etc. Then your pdos_write - and hence any app
> which uses it - would work on any of them, though you'd need to supply
> the different write handlers.

It is my intention that with the C90-like non-bios I mentioned
above, that the non-bios would simply translate a nonbios->printf
into an actual printf provided by whatever C compiler/library was
being used on some arbitrary host like AmigaOS.

Note that with AmigaOS in particular there is not any real
option of replacing AmigaOS. I have to run PDOS
(which will be Amiga-PDOS) under it. There is no problem
presenting a C:\ prompt to the user, but the C drive will
simply be a flat file up to 2 GiB that is accessed by the
standard non-bios Amiga OS C program.

There is also no problem providing a FAT file system (on
that emulated disk), and no problem calling my executables
fred.exe or whatever.

But fred.exe would be an almost-standard AmigaOS C program.

I say almost-standard because I can only run programs that
are aware of the D7 extension that provides an override to
address 4. Because AmigaPDOS will not have access to
address 4. That is owned by AmigaOS.

All PDPCLIB-based programs are D7-extension-aware.

But as usual, currently I believe ONLY PDPCLIB-based
programs are D7-extension-aware. :-)

The D7 extension was thrashed out with people over on
an Amiga forum. They weren't particularly impressed, but
they did help me select a register and explain why that
one was most appropriate for what I was trying to do.

BTW, it was only over on the Amiga forum where someone
explained to me that the BIOS exists to abstract the
hardware. And it was only there that I learnt about address
4 on the Amiga, and a different way of obtaining OS
services. Before that it was always INT/SVC/trap for me.

I did know about z/OS Unix having pointers in the CVT,
but for some reason that didn't have the required impact
on me.

It is the Amiga that got me to come up with PDOS-generic
and nearly abandon PDOS/386. I literally did abandon
PDOS/386 - I told a Slovakian that he could do whatever
he wanted in "src" - I had lost interest in it. But later I
realized that there was no harm continuing it until
conclusion before refocusing on PDOS-generic.

PDOS-generic should run under PDOS/3X0 and
PDOS/386 (and Windows and Linux) while waiting
for a more sophisticated non-bios to be loaded as
part of the PDOS/386 boot sequence on real
hardware.

BFN. Paul.

wolfgang kern

unread,
Jul 3, 2021, 8:29:50 AMJul 3
to
On 02.07.2021 17:42, Scott Lurndal wrote:
...
>> Note that that "desire" was for illustration purposes only.
>> I couldn't give a shit about crap like Linux.

> And the rest of us don't give a shit about useless crap like PDOS,
> FAT, BIOS or S/370.

Amen.
__
wolfgang

Joe Monk

unread,
Jul 3, 2021, 9:43:13 AMJul 3
to

> > And the rest of us don't give a shit about useless crap like PDOS,
> > FAT, BIOS or S/370.

You forgot EBCDIC ANSI.

Joe

Scott Lurndal

unread,
Jul 3, 2021, 11:07:54 AMJul 3
to
Rod Pemberton <noe...@basdxcqvbe.com> writes:
>On Fri, 02 Jul 2021 15:42:49 GMT
>sc...@slp53.sl.home (Scott Lurndal) wrote:
>
>> "muta...@gmail.com" <muta...@gmail.com> writes:
>> >On Friday, July 2, 2021 at 7:05:55 PM UTC+10, Rod Pemberton wrote:
>
>> >> > I want to run Linux executables from PDOS/386, running
>> >> > as an unprivileged program running under Windows 10.
>> >> > I don't have access to INT 80H so the executable will
>> >> > fail (unless I was to somehow scan the executable and
>> >> > zap them all into callbacks).
>> >
>> >Note that that "desire" was for illustration purposes only.
>> >I couldn't give a shit about crap like Linux.
>>
>> And the rest of us don't give a shit
>
>Honestly, I don't think that Paul's comments were intended to be as
>harsh as you've apparently been taking them. He's downunder.

Perhaps, but I think his hatred for linux has been made clear over
the past years.
>
>> And the rest of us don't give a shit about useless crap like PDOS,
>> FAT, BIOS or S/370.

Perhaps a bit tongue in cheek.

>
>So, Scott, are you working on your own OS? I apparently missed
>your mention of it. So, what are you planning to do? You're here for
>a good reason, right?

I've worked on five new operating systems over the last forty
years. They've all been for state of the art hardware (and
state of the art software, I wrote an early pre-vmware hypervisor
in the late 90's, for example). Most were for very large systems
(mainframes in the 80's, massively parallel distributed systems
in the 90's, linux in the 2000s and a distributed shared memory
hypervisor in the late 2000s).

>
>
>Personally, I'm in the world of EXT4 and BIOS and 64-bit (Linux).
>Although, I'm still in the world of FAT and BIOS and 32-bit (MS-DOS).
>No UEFI, yet though, which will be a total mess if there is no BIOS
>support anymore via CSM.

The product I currently work on is 64-bit (ARMv9) with UEFI and/or
UBOOT (depending on customer) and we provide the firmware. Our most
recent product is a large DPU with more 24 cores, 100Gb ethernet,
dozens of hardware coprocessors (including machine learning), a
security coprocessor and a management coprocessor.

It generally runs Linux (DPDK is the primary application).


>I'd doubt that most others here have moved to
>UEFI, as you're about the only one who mentions it.

I get the impression that most here are more interested in
legacy systems from the 1970s/1980's - i.e. systems they
grew up on.

I'd much rather develop operating systems for state-of-the-art
hardware (which is why I always worked for system manufacturers
or processor design companies).

I have a nice simulator for Burroughs mainframes (for which I
wrote parts of the operating system - including the code that
took the system from power-off to idle) that I play
with for a hobby, but these days, I'd much rather go walking
on the beach.

>
>I do understand your perspective. Tool did say in their song A-Enema
>(AEnema), "Yeah, f--k retro anything," ... as well as wishing that the
>"hopeless f--king hole" called Los Angeles would be flushed out (via an
>implicit enema) into the Arizona Bay (the sea water offshore of Arizona
>once California sinks) via an AEnima (with 'i' not 'e') event which is
>an apocalyptic event of sinking underwater like Atlantis, and also the
>name of their album.

A common misconception (The Burroughs plant was in Pasadena at the
time). The land moves laterally along the fault.

>
>
>We - the rest of us, the 49% of America not dumb enough to put an
>incompetent vegetable and radical Muslim terrorist into the White House
>- can solidly say the same, "flush it all away", but about the whole of
>California, and it's radically politically biased socialist government
>and it's overbearing paternalistic censorial suppressive tech
>companies, can't we? They don't represent America or it's values,

So you digress into a ridiculous political diatribe.

So much for rational thought.

Scott Lurndal

unread,
Jul 3, 2021, 1:32:47 PMJul 3
to
Modern Linux applications almost _never_ have INT instructions.(or SYSCALL
or SYSENTER isntructions) in them. Even 32-bit applications.

The INT/SYSCALL instructions are in the libc shared object, the applications
simply call indirectly through a global pointer table into libc. LIBC will
take care of any interactions with the operating system isolating the
application from the operating system.

Therefore, to run a linux application on a foreign operating system
simply requires a version of libc that uses the foreign operating system
interface instructions (INT, Call Gate, SYSENTER or SYSCALL).

The above is true for dynamically linked applications. Statically linked
applications (which are rather rare) will include the required libc
function code in the ELF executable itself and thus may not be portable
to operating systems with different methods of communicating with the
operating system (or any higher privileged ring of execution).



>
> https://man7.org/linux/man-pages/man2/write.2.html
>
>and how to get it to be pulled in by dynamic linking.

That's exactly what happens. The application includes
the proper header file and codes a call to the write
function and links against libc. When executed,
it will call through a vector of APIs
into the system C library (libc) which then communicates
to the operating system, if required.

Branimir Maksimovic

unread,
Jul 3, 2021, 7:12:09 PMJul 3
to
This is how looks modern assembler on GNU/Linux on an x86:

;-------------------------------------
include 'format/format.inc'

format ELF64 executable ELFOSABI_LINUX
entry start

include 'import64.inc'

interpreter '/lib64/ld-linux-x86-64.so.2'
needed 'libc.so.6'
import printf,exit

segment readable executable

start:

lea rdi,[msg]
xor eax,eax
call [printf]

call [exit]

segment readable writeable
msg db 'Hello world!',0xA,0
;------------------------------------------

>

muta...@gmail.com

unread,
Jul 3, 2021, 9:26:06 PMJul 3
to
On Sunday, July 4, 2021 at 3:32:47 AM UTC+10, Scott Lurndal wrote:

> The INT/SYSCALL instructions are in the libc shared object, the applications
> simply call indirectly through a global pointer table into libc.

And the global pointer is accessed via the parameter
after envp?

And other languages (Fortran etc) (can) make use of that
same pointer?

If so, that's exactly what I want.

And then I want PDPCLIB to be converted into a replacement
for libc, in the same way that Alica turned PDPCLIB into a
replacement for msvcrt.dll.

BFN. Paul.

Rod Pemberton

unread,
Jul 4, 2021, 2:15:20 AMJul 4
to
Are you saying political discourse is irrational or just off-topic? ;-)


BTW, with that resume, you're likely to have the most and best success
of anyone here with developing an OS. IIRC, wolfgang is the only one
with a commercially successful OS. Most of the people who've come and
gone from here over the past 15 years have never reached the point of
open source OS or a commercial product.

Paul has recently returned after about a 10 year hiatus.

Rod Pemberton

unread,
Jul 4, 2021, 2:23:09 AMJul 4
to
On Sat, 03 Jul 2021 17:32:45 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:

> The INT/SYSCALL instructions are in the libc shared object, the
> applications simply call indirectly through a global pointer table
> into libc. LIBC will take care of any interactions with the
> operating system isolating the application from the operating system.

He's creating a standalone OS, which he is executing under a hosted OS.

So, in general, his operating system (OS) application mustn't call the
host OS' functions, since it should work as a freestanding OS too.

So, he really has only a few development paths:

a) his OS app -> libc -> host OS functions -> trap & replace
b) his OS app -> no libc
c) his OS app -> custom libc for his OS
d) his OS app -> only libc functions independent of the host OS

So, let's review those options.


Option a):

Option a) is what Paul is struggling with.


Option b):

Option b) is doable but isn't quick nor easy.


Option c):

Option c) is the path chosen by most of the hobby OSes I sampled on the
Internet circa 2007, i.e., path of least resistance. This option is not
that difficult as an OS only needs a few library functions, and most C
libraries are built-up from just a handful of OS functions, e.g.,
Plauger's "The Standard C Library" book and Redhat's newlib use just 18
to 20 host OS calls. Ritchie and Thompson used 11 functions for
PDP-7/11. Early Linux had 40 syscalls, whereas 2.6.17 kernel has 290.

Paul can look a a list of those functions here in this post of mine:
https://groups.google.com/g/alt.os.development/c/ZakDSkdPyS4/m/jLzIpSzMHhMJ


Option d):

Option d) is in regards to which parts of the C library can be host
independent and therefore usable. So, this is from an old post of
mine:

"Some C library functions, such as character functions (is*, to*),
memory functions (mem*), string functions (str*), sprintf() scanf() etc
are likely to NOT be dependent on your OS, due to simplicity and simple
use of memory. Things like argc, argv, exit, stdio, stdin, stderr are
OS dependent on the OS to app interface. File I/O is clearly OS
dependent on at least six to eight OS functions at a minimum. Memory
allocation is OS dependent. File I/O is likely dependent on memory
allocation too. The initial stack used by most compiled C code may be
dependent on memory allocation. This depends. It may use alloca() or
another method, perhaps set up in assembly. The library is dependent
on the OS."


With the GCC compiler, there are compiler options like -ffreestanding
and linker options like -nostdlib for producing freestanding or
standalone apps. -nostdlib enables -nodefaultlibs and -nostartfiles.

According to this webpage, if he's using GCC, he'll still have to
provide some functions like memcpy(), memmove(), memset(), and memcmp()
for freestanding GCC apps.
http://cs107e.github.io/guides/gcc/

If he's not using GCC, he'll have to search the compiler documentation,
or even modify the compiler, e.g., Small C or Smaller C etc.

> Therefore, to run a linux application on a foreign operating system
> simply requires a version of libc that uses the foreign operating
> system interface instructions (INT, Call Gate, SYSENTER or SYSCALL).
>
> The above is true for dynamically linked applications. Statically
> linked applications (which are rather rare) will include the required
> libc function code in the ELF executable itself and thus may not be
> portable to operating systems with different methods of communicating
> with the operating system (or any higher privileged ring of
> execution).
>

Bingo.

That static code if not compiled with special compiler options such as
those mentioned for GCC above results in calling the host OS' internal
functions, which his OS app shouldn't be calling if he wants it to be
standalone or freestanding.

muta...@gmail.com

unread,
Jul 4, 2021, 4:26:02 AMJul 4
to
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, but
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.

So I wish to run gccwin under PDOS-generic
(essentially the same as PDOS/386 but with the
BIOS decoupled and encapsulated in PDPCLIB,
and FAT encapsulated in PDPCLIB).

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.

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.

The BIOS layer may or may not INSTEAD be called
BOOTX32.EFI or whatever 32-bit UEFI is.

The BIOS layer may or may not INSTEAD be called
BOOTX64.EFI and switching from 32 to 16 to 64
to 16 to 32.

If the BIOS layer is a simple Windows program running
under some PDOS-generic like OS, the layers can go
up and up forever until you find someone who does an
actual INT instruction or manipulates the hardware.

BFN. Paul.

Joe Monk

unread,
Jul 4, 2021, 8:04:48 AMJul 4
to

> I'm not 100% sure I understand your summary, but
> 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.
>
> So I wish to run gccwin under PDOS-generic
> (essentially the same as PDOS/386 but with the
> BIOS decoupled and encapsulated in PDPCLIB,
> and FAT encapsulated in PDPCLIB).

Well ... gccwin has dependencies on either: CYGWIN or MINGW or MINGW-X64, depending on the version of Windows.

Joe

muta...@gmail.com

unread,
Jul 4, 2021, 9:09:33 AMJul 4
to
Welcome to 2021. Specifically about 1 week ago in 2021.
We now have a gccwin that is C90-compliant and only
dependent on the C90 subset of msvcrt.dll that is also
present in the PDPCLIB version of msvcrt.dll.

It is actually the C compiler I recommend for general use.
Can be compiled from source using just a C compiler,
including itself. Doesn't need bash or cygwin. The makefile
doesn't use tabs and can be processed by pdmake.

I use it myself for a reason.

BFN. Paul.

Joe Monk

unread,
Jul 4, 2021, 9:39:10 AMJul 4
to

> Welcome to 2021. Specifically about 1 week ago in 2021.
> We now have a gccwin that is C90-compliant ...

Then its not gccwin.

https://gcc.gnu.org/install/specific.html#windows

I don't see a non mingw or cygwin version for windows in that list anywhere.

Joe

muta...@gmail.com

unread,
Jul 4, 2021, 9:50:52 AMJul 4
to
I did a search for "gccwin" on that link and found 0 hits.

I did a search for "gccwin" at http://pdos.org and found 2 hits.

Maybe you need to update your bookmarks.

Incidentally, I was wrong about the 1 week ago. The technology
was only signed off on 1st July 2021 when I walked a
non-programmer through the installation process of gccwin
(which consists of nothing more than unzipping the binaries
into a directory in your PATH), and it all worked without a
single hitch. Although it did eventuate in a number of updates
to the above link to clarify things.

And if you want to be pedantic, I have asked the non-programmer
(who is basically now a programmer) to create a document
explaining the steps. So depending on your skill level, you
may need to wait for that document for the technology to be
signed off to the level you require.

And if you want to be extra pedantic, and see evidence that
the non-programmer-now-programmer has the ability to
recompile the gccwin source using nothing more than the
gccwin.exe they have already installed (plus the source
code), then that will probably take another week or two,
unless you are happy to accept the evidence of a
Vietnamese programmer-who-was-a-programmer-already,
although only a recent graduate from a Vietnamese
university.

BFN. Paul.

Joe Monk

unread,
Jul 4, 2021, 12:06:21 PMJul 4
to

> I did a search for "gccwin" on that link and found 0 hits.
>
> I did a search for "gccwin" at http://pdos.org and found 2 hits.
>
> Maybe you need to update your bookmarks.

Maybe you shouldnt name your products the same as others already out there in order to avoid confusion!

A quick google search shows plenty of hits on gccwin.

Joe

muta...@gmail.com

unread,
Jul 4, 2021, 6:05:25 PMJul 4
to
On Monday, July 5, 2021 at 2:06:21 AM UTC+10, Joe Monk wrote:

> Maybe you shouldnt name your products the same as others already out there in order to avoid confusion!
>
> A quick google search shows plenty of hits on gccwin.

I have never seen an executable called gccwin, gcc386
or gccmvs, other than what I produced myself.

BFN. Paul.

Rod Pemberton

unread,
Jul 5, 2021, 5:24:11 AMJul 5
to
On Sun, 4 Jul 2021 01:26:01 -0700 (PDT)
"muta...@gmail.com" <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., <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 ...)

> 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.

muta...@gmail.com

unread,
Jul 5, 2021, 9:45:44 AMJul 5
to
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., <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
nor cares.

> 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
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.

> 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:

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.

Scott Lurndal

unread,
Jul 5, 2021, 11:29:07 AMJul 5
to
"muta...@gmail.com" <muta...@gmail.com> writes:
>On Sunday, July 4, 2021 at 3:32:47 AM UTC+10, Scott Lurndal wrote:
>
>> The INT/SYSCALL instructions are in the libc shared object, the applications
>> simply call indirectly through a global pointer table into libc.
>
>And the global pointer is accessed via the parameter
>after envp?

The application is encapsulated in a ELF (Extensible Linkage Format)
file. The ELF file includes two memory-resident data structures
called the PLT (Procedure Linkage Table) and the GOT (Global Offset Table).

The PLT is a vector of function pointers that the application uses to
access the shared library functions.

The GOT is a vector of data pointers to global data provided by the
shared object.

When a dynamically linked ELF executable is executed, a special shim
library (called the run-time loader - RTLD) is first loaded. It then
loads the appropriate sections (text/data/bss) from the ELF into memory
and locates the dynamic section in the ELF file. The dynamic section lists
all the dynamic dependencies (e.g. shared objects) that are required
to satisfy the external dependencies of the applications (e.g. POSIX
interfaces such as read, write, lseek, et alia).

While loading the shared objects on behalf of the application, the RTLD
will fill in the GOT and PLT tables with the virtual addresses that the
shared objects are loaded at (they can be different from run to run
and each application will load the shared objects at different virtual
addresses in the application).

The application then branches through the PLT to get to 'write', 'read',
'open', 'fopen', 'fclose', 'printf' etc.

Accesses to global data provided by the shared objects (e.g. certain
external global variables supported by the API supplied by the shared
object) is indirectly provided via the GOT.

>
>And other languages (Fortran etc) (can) make use of that
>same pointer?

Yes, the ELF files and run-time linking capabilities are independent
of the source language.

Scott Lurndal

unread,
Jul 5, 2021, 3:01:57 PMJul 5
to
I should point out that the PLT entries can either be bound at
startup or can be lazily bound. In the later case, the PLT entry initially
branches to a function that will lookup the symbol and update the
PLT entry the first time the function is called.

muta...@gmail.com

unread,
Jul 5, 2021, 6:13:34 PMJul 5
to
On Tuesday, July 6, 2021 at 1:29:07 AM UTC+10, Scott Lurndal wrote:

> While loading the shared objects on behalf of the application, the RTLD
> will fill in the GOT and PLT tables with the virtual addresses that the
> shared objects are loaded at (they can be different from run to run
> and each application will load the shared objects at different virtual
> addresses in the application).
>
> The application then branches through the PLT to get to 'write', 'read',
> 'open', 'fopen', 'fclose', 'printf' etc.

This sounds exactly like Windows.

And that is very different from UEFI, which passes a pointer
of callable functions, right?

Which one is better in your opinion - UEFI or Linux?

And UEFI actually takes 2 parameters, not one. Are
two necessary/desirable?

And under what circumstances should the parameter
after envp be used?

Thanks. Paul.

Joe Monk

unread,
Jul 5, 2021, 7:03:21 PMJul 5
to

> Which one is better in your opinion - UEFI or Linux?

Linux runs on top of UEFI.

Joe

muta...@gmail.com

unread,
Jul 5, 2021, 7:25:51 PMJul 5
to
On Tuesday, July 6, 2021 at 9:03:21 AM UTC+10, Joe Monk wrote:

> > Which one is better in your opinion - UEFI or Linux?

> Linux runs on top of UEFI.

That is not my question.

Linux executables rely on the caller filling in external references.

UEFI executables rely on the caller passing 2 pararameters.

Which is better, and why?

And is 2 parameters better than 1?

Thanks. Paul.

muta...@gmail.com

unread,
Jul 5, 2021, 7:28:58 PMJul 5
to
On Tuesday, July 6, 2021 at 9:25:51 AM UTC+10, muta...@gmail.com wrote:

> Linux executables rely on the caller filling in external references.
>
> UEFI executables rely on the caller passing 2 pararameters.

caller = loader

Branimir Maksimovic

unread,
Jul 5, 2021, 7:50:47 PMJul 5
to
On 2021-07-05, muta...@gmail.com <muta...@gmail.com> wrote:
>
> And under what circumstances should the parameter
> after envp be used?

At the beginning of program you obtain pointer and use it instead of int 80h.
Benefit is it was faster on older hardwer, now not worth a fuss...
>
> Thanks. Paul.

muta...@gmail.com

unread,
Jul 5, 2021, 8:05:21 PMJul 5
to
On Tuesday, July 6, 2021 at 9:50:47 AM UTC+10, Branimir Maksimovic wrote:

> > And under what circumstances should the parameter
> > after envp be used?

> At the beginning of program you obtain pointer and use it instead of int 80h.
> Benefit is it was faster on older hardwer, now not worth a fuss...

Not worth a fuss because what?

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.

Thanks. Paul.

Scott Lurndal

unread,
Jul 5, 2021, 8:30:29 PMJul 5
to
Joe Monk <joem...@gmail.com> writes:
>
>> Which one is better in your opinion - UEFI or Linux?
>
>Linux runs on top of UEFI.

I believe it more accurate to state that Linux runs alongside of UEFI,
in the sense that UEFI lives in memory marked reserved in the memory map
it provides to the operating system (Windows, VMware, Linux, Wind River, etc).

The operating system may then request services from the UEFI code dealing
with low-level hardware-specific interfaces (such as firmware updates,
sensor management, performance monitoring).

muta...@gmail.com

unread,
Jul 5, 2021, 9:28:03 PMJul 5
to
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.

Branimir Maksimovic

unread,
Jul 5, 2021, 10:51:50 PMJul 5
to
Why you are bothered with int 80h? Why don't you use glibc
then you don't need syscalls directly?
Yes with vsyscall you don't need int 80h if that suits you...
>
> Thanks. Paul.

muta...@gmail.com

unread,
Jul 5, 2021, 11:21:08 PMJul 5