On Wed, 21 Feb 2024 21:54:02 +0800, Paul Edwards wrote:
[snip]
> When the ELF executable is run on PDOS/386, I will
> have no way of knowing that this open is text, and
> thus PDOS/386 (the OS) should add CRs whenever it
> sees a LF.

ISTM that you are looking at this from the wrong end.

POSIX open() does not make a distinction between a "text"
and a "binary" file; all files are "binary". Programs
(including Linux programs) that are coded to the POSIX
standard already accommodate this. So, any code you port
from a Linux environment (either source code or ELF
executable) is already in a state to read and write
a binary file. Given this, then there is no need for
an O_TEXT flag for a Linux program, as no Linux program
expects open() to provide special conditions for text
data.

Given this, there only one problem to resolve: how to
allow for text data to be interchanged transparently
between the MSDOS/Windows side of your PDOS/386 and
the Linux side.

And, that's not the problem you are chasing ATM.

[snip]

--
Lew Pitcher
"In Skills We Trust"

On 22/02/24 04:28, Lew Pitcher wrote:
> On Wed, 21 Feb 2024 21:54:02 +0800, Paul Edwards wrote:
> [snip]
>> When the ELF executable is run on PDOS/386, I will
>> have no way of knowing that this open is text, and
>> thus PDOS/386 (the OS) should add CRs whenever it
>> sees a LF.
>
> ISTM that you are looking at this from the wrong end.
>
> POSIX open() does not make a distinction between a "text"
> and a "binary" file; all files are "binary". Programs

Sure. And I'm talking about changing POSIX to
add the distinction, for anyone who has a use
for such a thing.

> (including Linux programs) that are coded to the POSIX
> standard already accommodate this. So, any code you port
> from a Linux environment (either source code or ELF
> executable) is already in a state to read and write
> a binary file.

This would be new code obviously, and include
an O_TEXT.

> Given this, then there is no need for
> an O_TEXT flag for a Linux program, as no Linux program
> expects open() to provide special conditions for text
> data.

I want to be able to WRITE such a Linux program.

> Given this, there only one problem to resolve: how to
> allow for text data to be interchanged transparently
> between the MSDOS/Windows side of your PDOS/386 and
> the Linux side.

PDOS/386 *will be Linux*. A mini-clone. Also a
mini-clone of OS/2. It's already a mini-clone
of Windows, and sort of a clone of MSDOS too.

All on a 360k floppy.

The only question is - on this all-encompassing OS -
are text files going to follow DOS (CP/M) convention
or Unix convention?

And currently I am going for CP/M, which means my
Linux executables need to provide the appropriate
information so that they run seamlessly in this
CP/M-standard environment.

One day I'll probably do the reverse. And since it
is the C library that is adding CRs for Windows,
it will require a similar enhancement for the
Windows CreateFile() interface to pass a "text"
flag so that PDOS/386 can STRIP the CRs that will
be flowing through.

But that looks even more difficult:

https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea

BFN. Paul.

On 21/02/24 22:20, Richard Kettlewell wrote:
> Paul Edwards <mutazilah@gmail.com> writes:
>> On 21/02/24 20:25, Richard Kettlewell wrote:
>>> Standard C doesn’t have open(), read() or write() either,
>>
>> Indeed - because PDPCLIB's implementation of fopen()
>> needs to do the open syscall (INT 80H EAX = 5H).
>>
>> fopen already knows whether the file is being opened as text or
>> binary, and I don't want that information lost when I do that
>> interrupt above. Even though Linux (currently, and very likely
>> forever) won't use it, PDOS/386 has a use for it (in the short term).
>>
>>> but you seem to want to modify the behaviour of those.
>>
>> I don't think that is an accurate statement.
>>
>> What behavior, where?
>
> You’ve been talking about doing translation _somewhere_,

Yes - when run under PDOS/386.

Currently the only Linux ELF program that runs
under PDOS/386 is a "hello world".

And I don't think anyone cares if I change the
behavior of that.

And that program doesn't even use open(), so is
not subject to my proposed change.

I guess I am talking about changing FUTURE
behavior of a FUTURE program.

But I thought you were implying I was going
to break something.

> and cited
> Cygwin as an example in your first posting, and have been consistently
> using the flag name from Cygwin. Cygwin’s O_TEXT causes read() and
> write() to translate between newline conventions, so if you meant
> something else then it was a confusing decision to use Cygwin as an
> example.

Cygwin is a correct example, I believe.

And Cygwin doesn't change the behavior of Linux ELF
executables either.

Nor does it change the behavior of existing POSIX
source code.

> If, in fact, you don’t want to add translation to read() and write()

I do.

I guess it's just a semantic debate as to whether
this constitutes a change in behavior.

All existing Linux ELF programs are unchanged.

Even new Linux ELF programs won't change when
run under Linux.

The flag only takes effect when the ELF is run
on a competing system.

BFN. Paul.

Paul Edwards <mutazilah@gmail.com> writes:
> Cygwin is a correct example, I believe.
>
> And Cygwin doesn't change the behavior of Linux ELF
> executables either.

AFAIK it can’t run them at all, so I don’t know why that would be
relevant.

> Nor does it change the behavior of existing POSIX source code.

Your use case was C90 programs, not POSIX programs, last time you
mentioned it. Has that changed now?

>> If, in fact, you don’t want to add translation to read() and write()
> I do.

OK, so an ELF executable (that had been modified to use your
hypothetical O_TEXT flag) would get newline translation from read() and
write() when run on your toy OS, but not when run on a real Linux
kernel. There’s the change in behavior.

At any rate we’re back to the issue that you say want to add
Cygwin-style translation to read() and write(), but you also say that
you will only be running programs written in C90, which doesn’t have
open(), so nothing will ever pass O_TEXT and the translation will never
be activated.

> I guess it's just a semantic debate as to whether this constitutes a
> change in behavior.

This would go a lot quicker if you didn’t engage in “semantic debates”.

--
https://www.greenend.org.uk/rjk/

On 22/02/24 17:57, Richard Kettlewell wrote:
> Paul Edwards <mutazilah@gmail.com> writes:

>> Cygwin is a correct example, I believe.
>>
>> And Cygwin doesn't change the behavior of Linux ELF
>> executables either.
>
> AFAIK it can’t run them at all, so I don’t know why that would be
> relevant.

That's exactly the point - it doesn't run them.
No behavior is being changed by Cygwin either.

>> Nor does it change the behavior of existing POSIX source code.
>
> Your use case was C90 programs, not POSIX programs, last time you
> mentioned it. Has that changed now?

I am the vendor of a C90 runtime library for Linux (PDPCLIB).

fopen() necessarily does an open syscall.

>>> If, in fact, you don’t want to add translation to read() and write()
>> I do.
>
> OK, so an ELF executable (that had been modified to use your
> hypothetical O_TEXT flag) would get newline translation from read() and
> write() when run on your toy OS, but not when run on a real Linux
> kernel. There’s the change in behavior.

Well you can call it that if you want. But as I said,
I think it is odd to call something a change in behavior
when the software that would be "changing" hasn't even
been written yet. Or at least, the INT 80H open() processing
of PDOS/386 hasn't been written yet. Only write to stdout
has been written so far. And exit.

Also, when you say "the ELF executable that has been
modified", I would use the word "built" rather than
"modified". I am building new ELF executables according
to a hypothetical version of POSIX/Linux that includes
a new O_TEXT definition.

> At any rate we’re back to the issue that you say want to add
> Cygwin-style translation to read() and write(), but you also say that
> you will only be running programs written in C90, which doesn’t have
> open(), so nothing will ever pass O_TEXT and the translation will never
> be activated.

PDPCLIB will do that.

I clearly haven't done a very good job of explaining
what I want.

I am organizing contact with the "Austin Group" (I've
become a member and downloaded the latest POSIX draft).

Is there any wording I should use to avoid the several
days of confusion we've had here?

When I wrote my original message I thought it was a very
simple suggestion, using the widely-known Cygwin prior art.

Instead, I'm not even sure my proposal is understood.

>> I guess it's just a semantic debate as to whether this constitutes a
>> change in behavior.
>
> This would go a lot quicker if you didn’t engage in “semantic debates”.

I wasn't attempting to. I was just trying to identify
the point of contention as semantics, not a technical
issue.

It's still not clear to me that it really is semantics,
because you are using language that I wouldn't use.

BFN. Paul.

On 22/02/2024 10.57, Richard Kettlewell wrote:
> Paul Edwards <mutazilah@gmail.com> writes:

>> I guess it's just a semantic debate as to whether this constitutes a
>> change in behavior.
>
> This would go a lot quicker if you didn’t engage in “semantic debates”.

For me it whole feels like a repeat of systemd when they stupidly picked
a namespace already used by the kernel and wanted the kernel to change
nem of their namespace.

The whole can be solved in the header to define missing macro.

--
//Aho

On 22/02/24 20:48, J.O. Aho wrote:
> On 22/02/2024 10.57, Richard Kettlewell wrote:
>> Paul Edwards <mutazilah@gmail.com> writes:
>
>>> I guess it's just a semantic debate as to whether this constitutes a
>>> change in behavior.
>>
>> This would go a lot quicker if you didn’t engage in “semantic debates”.
>
> For me it whole feels like a repeat of systemd when they stupidly picked
> a namespace already used by the kernel and wanted the kernel to change
> nem of their namespace.
>
> The whole can be solved in the header to define missing macro.

Define it to what? That's my original question.

And by who?

BFN. Paul.

On Thu, 22 Feb 2024 21:49:19 +0800, Paul Edwards wrote:

> On 22/02/24 20:48, J.O. Aho wrote:
>> On 22/02/2024 10.57, Richard Kettlewell wrote:
>>> Paul Edwards <mutazilah@gmail.com> writes:
>>
>>>> I guess it's just a semantic debate as to whether this constitutes a
>>>> change in behavior.
>>>
>>> This would go a lot quicker if you didn’t engage in “semantic debates”.
>>
>> For me it whole feels like a repeat of systemd when they stupidly picked
>> a namespace already used by the kernel and wanted the kernel to change
>> nem of their namespace.
>>
>> The whole can be solved in the header to define missing macro.
>
> Define it to what? That's my original question.

That's up to whomever defines it.

> And by who?

That would be you. And /not/ by Linux.

--
Lew Pitcher
"In Skills We Trust"

Paul Edwards <mutazilah@gmail.com> writes:
> On 22/02/24 17:57, Richard Kettlewell wrote:
>> Paul Edwards <mutazilah@gmail.com> writes:
>
>>> Cygwin is a correct example, I believe.
>>>
>>> And Cygwin doesn't change the behavior of Linux ELF
>>> executables either.
>>
>> AFAIK it can’t run them at all, so I don’t know why that would be
>> relevant.
>
> That's exactly the point - it doesn't run them.
> No behavior is being changed by Cygwin either.

The behavior of read() and write() is changed by the O_TEXT flag in
Cygwin.

>>> Nor does it change the behavior of existing POSIX source code.
>>
>> Your use case was C90 programs, not POSIX programs, last time you
>> mentioned it. Has that changed now?
>
> I am the vendor of a C90 runtime library for Linux (PDPCLIB).
>
> fopen() necessarily does an open syscall.

If a file was opened with fopen() then the stdio functions (putc, fread,
etc) can do the newline translation. No need to mess with the behavior
read() and write(). But I think we’ve been round that loop and for
unknown reasons you still seem to want to do it the hard way.

>>>> If, in fact, you don’t want to add translation to read() and write()
>>> I do.
>>
>> OK, so an ELF executable (that had been modified to use your
>> hypothetical O_TEXT flag) would get newline translation from read() and
>> write() when run on your toy OS, but not when run on a real Linux
>> kernel. There’s the change in behavior.
>
> Well you can call it that if you want. But as I said, I think it is
> odd to call something a change in behavior when the software that
> would be "changing" hasn't even been written yet. Or at least, the
> INT 80H open() processing of PDOS/386 hasn't been written yet. Only
> write to stdout has been written so far. And exit.

Once again, this would go a lot quicker if you didn’t engage in
“semantic debates”.

> Also, when you say "the ELF executable that has been modified", I
> would use the word "built" rather than "modified". I am building new
> ELF executables according to a hypothetical version of POSIX/Linux
> that includes a new O_TEXT definition.

If it’s unmodified then it won’t set O_TEXT.

>> At any rate we’re back to the issue that you say want to add
>> Cygwin-style translation to read() and write(), but you also say that
>> you will only be running programs written in C90, which doesn’t have
>> open(), so nothing will ever pass O_TEXT and the translation will
>> never be activated.
>
> PDPCLIB will do that.

If you control the C library then you can do the translation in the
<stdio.h> implementation; there is no need to mess with the behavior of
read() and write().

> I clearly haven't done a very good job of explaining what I want.

Indeed.

--
https://www.greenend.org.uk/rjk/

On 22/02/24 22:55, Lew Pitcher wrote:
> On Thu, 22 Feb 2024 21:49:19 +0800, Paul Edwards wrote:
>
>> On 22/02/24 20:48, J.O. Aho wrote:
>>> On 22/02/2024 10.57, Richard Kettlewell wrote:
>>>> Paul Edwards <mutazilah@gmail.com> writes:
>>>
>>>>> I guess it's just a semantic debate as to whether this constitutes a
>>>>> change in behavior.
>>>>
>>>> This would go a lot quicker if you didn’t engage in “semantic debates”.
>>>
>>> For me it whole feels like a repeat of systemd when they stupidly picked
>>> a namespace already used by the kernel and wanted the kernel to change
>>> nem of their namespace.
>>>
>>> The whole can be solved in the header to define missing macro.
>>
>> Define it to what? That's my original question.
>
> That's up to whomever defines it.
>
>> And by who?
>
> That would be you. And /not/ by Linux.

That's not correct.

I can't properly define it myself. If I define it
myself, to an arbitrary value, then the ELF executable
will do strange things now or in the future when run
on Linux.

ie if I take over an existing flag or flags, or
choose a currently unused bit.

Again - I've clearly done a really really crappy
job of explaining what I want.

I don't know what I'm doing wrong.

Is there anyone who actually understands my
suggestion who can translate English to English?

I'll need a translated version for when I speak
to the Austin group otherwise I'll be going around
the exact same circle.

It's possible that I have some "unstated assumptions".
I have found that a problem in the past. But I don't
know what they are until after a lot of discussion.

I can take a guess though.

My goal for PDOS/386 is not to run *ANY* *EXISTING*
Linux ELF binaries.

My goal is to run *SPECIFIC* *FUTURE* Linux ELF
binaries.

Specifically ones linked with PDPCLIB where I have
done very specific things (which I control) so that
THE BINARIES work on BOTH Linux and PDOS/386.

I'm not attempting to create a Linux clone. I'm only
trying to create a very limited clone.

And I'm not trying to get CRs on Linux. I'm only
trying to get CRs on PDOS/386.

Again - I thought I explained it adequately, but of
course I always think that, but this is not the first
time I have been mistaken about what is "clear".

BFN. Paul.

On 22/02/24 23:34, Richard Kettlewell wrote:
> Paul Edwards <mutazilah@gmail.com> writes:
>> On 22/02/24 17:57, Richard Kettlewell wrote:
>>> Paul Edwards <mutazilah@gmail.com> writes:
>>
>>>> Cygwin is a correct example, I believe.
>>>>
>>>> And Cygwin doesn't change the behavior of Linux ELF
>>>> executables either.
>>>
>>> AFAIK it can’t run them at all, so I don’t know why that would be
>>> relevant.
>>
>> That's exactly the point - it doesn't run them.
>> No behavior is being changed by Cygwin either.
>
> The behavior of read() and write() is changed by the O_TEXT flag in
> Cygwin.

Sure - that's existing Cygwin that has *already
changed*. I'm not proposing a change to anything
that already exists.

>>>> Nor does it change the behavior of existing POSIX source code.
>>>
>>> Your use case was C90 programs, not POSIX programs, last time you
>>> mentioned it. Has that changed now?
>>
>> I am the vendor of a C90 runtime library for Linux (PDPCLIB).
>>
>> fopen() necessarily does an open syscall.
>
> If a file was opened with fopen() then the stdio functions (putc, fread,
> etc) can do the newline translation.

I don't WANT to do newline translation when *my*
binary *runs on Linux*.

I want my binaries to behave like any normal Linux program.

So I can't translate in the C library, unless the C
library does some sort of special call to detect the
environment and change behavior accordingly.

I think O_TEXT (with Cygwin prior art) is the neater
solution to this logical problem.

> No need to mess with the behavior
> read() and write().

No need to mess with the behavior of read() and
write() on WHICH SYSTEM?

PDOS/386 is the only thing that would be doing
any messing.

And that's far less mess than the alternative.

> But I think we’ve been round that loop and for
> unknown reasons you still seem to want to do it the hard way.

I don't consider this to be the hard way.

Can you suggest a syscall that I could use to detect
whether I am running under true Linux or PDOS/386
so that I can get the C library to adjust appropriately?

Also, the C library (as with Cygwin) may need to adjust
on a file-by-file basis. ie a syscall needs to be done
"do you want translation to be done on this particular
filename?". open() doesn't have the ability to return
such a status, so I would need to do a similar syscall
to open to find the translation requirements.

And this overhead needs to be added to (my) Linux programs
even when running on Linux - overhead for no purpose,
when a simple flag (that is ignored) is all that is required.

>>>>> If, in fact, you don’t want to add translation to read() and write()
>>>> I do.
>>>
>>> OK, so an ELF executable (that had been modified to use your
>>> hypothetical O_TEXT flag) would get newline translation from read() and
>>> write() when run on your toy OS, but not when run on a real Linux
>>> kernel. There’s the change in behavior.
>>
>> Well you can call it that if you want. But as I said, I think it is
>> odd to call something a change in behavior when the software that
>> would be "changing" hasn't even been written yet. Or at least, the
>> INT 80H open() processing of PDOS/386 hasn't been written yet. Only
>> write to stdout has been written so far. And exit.
>
> Once again, this would go a lot quicker if you didn’t engage in
> “semantic debates”.

I'm not deliberately engaging in semantic debates.

I'm just saying that if that's your definition, then
fine, yes, you're right, by that definition.

>> Also, when you say "the ELF executable that has been modified", I
>> would use the word "built" rather than "modified". I am building new
>> ELF executables according to a hypothetical version of POSIX/Linux
>> that includes a new O_TEXT definition.
>
> If it’s unmodified then it won’t set O_TEXT.

If *WHAT* is unmodified?

An existing ELF binary or one that I will build in
the future?

>>> At any rate we’re back to the issue that you say want to add
>>> Cygwin-style translation to read() and write(), but you also say that
>>> you will only be running programs written in C90, which doesn’t have
>>> open(), so nothing will ever pass O_TEXT and the translation will
>>> never be activated.
>>
>> PDPCLIB will do that.
>
> If you control the C library then you can do the translation in the
> <stdio.h> implementation; there is no need to mess with the behavior of
> read() and write().

Not true. The translation needs to be conditional.
So I need a different set of infrastructure to do
translation in the C library.

>> I clearly haven't done a very good job of explaining what I want.
>
> Indeed.

And I'm not doing that deliberately either.

I'm a native English speaker, but this is not the
first time I have failed to convey my message.

Sorry about that, but I don't know where I am
going wrong.

Maybe I can express it in C code/pseudocode.

Solution 1:

fopen()
{ if (strcmp(mode, "r")
{
flag |= O_TEXT; /* cannot be zero!!! */
}
syscall(syscall_open, name, flag);
}

Solution 2:

fopen()
{ if (strcmp(mode, "r")
{
rc = syscall(syscall_os_check);
if (rc == PDOS386) /* as opposed to GENUINE LINUX */
{
rc = syscall(syscall_check_translation, filename);
if (rc == TRANSLATION_REQUIRED)
{
FILE.translation_flag = 1;
}
}
}
}

fwrite()
{ if (FILE.translation_flag)
{
for (...) /* add CRs */
}
}

Let me know if the pseudocode is understandable,
or needs to be fleshed out in even more detail.

BFN. Paul.

On 23/02/2024 02.56, Paul Edwards wrote:
> On 22/02/24 22:55, Lew Pitcher wrote:
>> On Thu, 22 Feb 2024 21:49:19 +0800, Paul Edwards wrote:

>>> And by who?
>>
>> That would be you. And /not/ by Linux.
>
> I can't properly define it myself. If I define it
> myself, to an arbitrary value, then the ELF executable
> will do strange things now or in the future when run
> on Linux.

Try 0x0

You need to handle it in you own library pdpclib, do not expect others
to change for you think providing a file that isn't the one on disk is ok.

--
//Aho

Paul Edwards <mutazilah@gmail.com> writes:
>> No need to mess with the behavior read() and write().
>
> No need to mess with the behavior of read() and write() on WHICH
> SYSTEM?

Any system.

>> But I think we’ve been round that loop and for unknown reasons you
>> still seem to want to do it the hard way.
>
> I don't consider this to be the hard way.
>
> Can you suggest a syscall that I could use to detect
> whether I am running under true Linux or PDOS/386
> so that I can get the C library to adjust appropriately?

uname()

From another posting:

> Specifically ones linked with PDPCLIB where I have
> done very specific things (which I control) so that
> THE BINARIES work on BOTH Linux and PDOS/386.

Do you get that this is a weird requirement? You could just compile your
code twice, one for Linux and once for your toy platform.

--
https://www.greenend.org.uk/rjk/

On 23/02/24 17:25, J.O. Aho wrote:
> On 23/02/2024 02.56, Paul Edwards wrote:
>> On 22/02/24 22:55, Lew Pitcher wrote:
>>> On Thu, 22 Feb 2024 21:49:19 +0800, Paul Edwards wrote:
>
>>>> And by who?
>>>
>>> That would be you. And /not/ by Linux.
>>
>> I can't properly define it myself. If I define it
>> myself, to an arbitrary value, then the ELF executable
>> will do strange things now or in the future when run
>> on Linux.
>
> Try 0x0
>
> You need to handle it in you own library pdpclib, do not expect others
> to change for you think providing a file that isn't the one on disk is ok.

If it boils down to that, then I will do one of
the things I already mentioned.

I will define it to 0x8000 0000 or 0x4000 0000
or alter the definition of an existing flag
like NOATIME.

It will achieve what I want, even though it is
a bit odd when running on real Linux.

Any suggestions within those parameters?

Otherwise I will just choose one of those things
at random and carry on my merry way.

Probably I will chose 0x8000 0000 as Linux seems
to be working their way up the bits, so I will
take what I need working my way down the bits.

What I don't know yet is whether Linux will throw
an error for the unknown flag (0x8000 0000) or
whether they will in the future put in such a
check.

If they do, I then need to switch to commandeering
NOATIME or whatever and rebuilding my software.

BFN. Paul.

On 23/02/24 18:25, Richard Kettlewell wrote:
> Paul Edwards <mutazilah@gmail.com> writes:
>>> No need to mess with the behavior read() and write().
>>
>> No need to mess with the behavior of read() and write() on WHICH
>> SYSTEM?
>
> Any system.

There is a need, or at least, desire, to mess
with the behavior of read and write on PDOS/386,
for the exact same reason that Cygwin does.

It has no impact on anyone else.

>>> But I think we’ve been round that loop and for unknown reasons you
>>> still seem to want to do it the hard way.
>>
>> I don't consider this to be the hard way.
>>
>> Can you suggest a syscall that I could use to detect
>> whether I am running under true Linux or PDOS/386
>> so that I can get the C library to adjust appropriately?
>
> uname()

Thanks. I've just tested that (syscall 122).

root@kerravon2-pc:/home/kerravon/w2kshare# ./pdptest.exe
welcome to pdptest
buf is XLinuxX
buf + 65 is Xkerravon2-pcX
buf + 65 * 2 is X6.5.0-18-genericX
buf + 65 * 3 is X#18~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb 7
11:40:03 UTC 2X
buf + 65 * 4 is Xx86_64X
buf + 65 * 5 is X(none)X
m1 is 00000000

It looks to me like I need a buffer of size 6 * 65,
but I can add another 200 bytes and hope that is
enough.

It's not ideal, but it'll probably be sufficient.

And perhaps I could fudge this call so that on
PDOS/386 it returns 0x1234 as a magic number
instead of 0, so that I know it is PDOS/386.

That way I don't need to do a strcmp to a
particular system name. As I guess ultimately
I am trying to develop an alternative to POSIX.
So this could indicate that the alternative is
in effect.

And then if I am on a PDOS/386 (or POSIX-alternate)
system when I am opening a text file I can include a
flag of 0x8000 0000 to the open syscall.

> From another posting:
>
>> Specifically ones linked with PDPCLIB where I have
>> done very specific things (which I control) so that
>> THE BINARIES work on BOTH Linux and PDOS/386.
>
> Do you get that this is a weird requirement? You could just compile your
> code twice, one for Linux and once for your toy platform.

Sure - in fact I could just use the Win32 binaries.

But if I have to do that, I can no longer advertise
it as a "mini-Linux clone" that runs "properly-built"
Linux executables.

Where "properly-built" is something I just make up now
and roughly means "supports both POSIX and POSIX-alternate
systems".

BFN. Paul.

Note that I have a new pdos.zip at http://pdos.org
that implements this and other things (like a dummy
fork and trimmed exec so that system() from the
Linux app works on PDOS/386).

I went with O_TEXT of 0x4000 0000 so that 0x8000 0000
could be reserved to mean "more flags available in
another variable" or whatever.

Elsewhere someone told me that even if POSIX defined
O_TEXT, in Linux they could just set that to 0, so
it was Linux I needed, not POSIX.

So I wrote to the linux-kernel mailing list asking
for suggestions, but there was no reply so I went
ahead with the above.

Proof of concept for all features (another one is
command line with no Linux stack) can be found here:

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

And it runs this Linux test program:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/makefile.lnp

That concludes my immediate interest in Linux,
and I'm on to OS/2 that needs to be fleshed
out more.

BFN. Paul.

On 2024-02-21, Richard Kettlewell <invalid@invalid.invalid> wrote:
> Paul Edwards <mutazilah@gmail.com> writes:
>> On 21/02/24 10:51, Lew Pitcher wrote:
>>> If you are concerned with PDOS/386 being able to use source code written
>>> to the POSIX standard,
>>
>> Not just source - that is easy to deal with.
>> The executable.
>
> Executables won’t have your extra flag unless you’ve personally modified
> and recompiled them.

Some source targeted for DOS will have O_TEXT, Turbo C had this feature
in 1988 but if you go there you probably need to implement fmode also,

>>> The alternative is to specify that such a flag /is/ required for
>>> PDOS/386,
>>
>> That's the alternative I am after.
>>
>>> which restricts you to using code written specifically for PDOS/386,
>>> and
>>
>> It is only code that uses the new flag that will work nicely on
>> PDOS/386, yes.

> How will you modify other syscalls (for example fstat and lseek) to be
> play nicely with the newline translation?

They don't play nicely don't on DOS or Windows (or UTF-8 etc...)

This is probably not needed. I'm faily sure standards allow ftell and
fseek to deal in cookies on text files.

--
Jasen.
🇺🇦 Слава Україні

On 2024-02-22, Paul Edwards <mutazilah@gmail.com> wrote:
> On 22/02/24 17:57, Richard Kettlewell wrote:
>> Paul Edwards <mutazilah@gmail.com> writes:
>
>>> Cygwin is a correct example, I believe.
>>>
>>> And Cygwin doesn't change the behavior of Linux ELF
>>> executables either.
>>
>> AFAIK it can’t run them at all, so I don’t know why that would be
>> relevant.
>
> That's exactly the point - it doesn't run them.
> No behavior is being changed by Cygwin either.
>
>>> Nor does it change the behavior of existing POSIX source code.
>>
>> Your use case was C90 programs, not POSIX programs, last time you
>> mentioned it. Has that changed now?
>
> I am the vendor of a C90 runtime library for Linux (PDPCLIB).

As the vendor you get to choose the constants used in the header file
provided for compiling programs to link against your library.

you loose compatability with other standard libraries. but maybe
that's not a problem

> I think it is odd to call something a change in behavior
> when the software that would be "changing" hasn't even
> been written yet. Or at least, the INT 80H open() processing
> of PDOS/386 hasn't been written yet. Only write to stdout
> has been written so far. And exit.

--
Jasen.
🇺🇦 Слава Україні

On 2024-02-21, Paul Edwards <mutazilah@gmail.com> wrote:
> On 21/02/24 15:06, J.O. Aho wrote:
>
>>>>> And it is not important to maintain the same value
>>>>> as Cygwin, because Cygwin creates PE executables,
>>>>> while mine is for ELF executables.
>>>>
>>>> Are you just trying to keep your Linux source
>>>> source-compatible with your (Cygwin-based) Windows
>>>> source? Or are you actually looking for the functionality
>>>> behind the O_TEXT flag?
>>>
>>> The latter. Functionality on PDOS/386, not Linux.
>>
>> Think you need to look into the windows source code, as open() already
>> exists in windows
>
> There is no such syscall. kernel32 exports CreateFile.
>
> Regardless - Windows won't run the Linux ELF binary -
> not even the one I produce myself - regardless. Although
> if you install WSL it would, but that's installing
> Linux - and of course Linux programs run under Linux.
>
> It is PDOS/386 that will run it. And receive the
> INT 80H. And check for the flag.
>

so make you library figure out which OS is running and
remap the flags given to the to open() function call as
apropriate when translating to int80

--
Jasen.
🇺🇦 Слава Україні

On 29/02/24 21:16, Jasen Betts wrote:

> On 2024-02-21, Paul Edwards <mutazilah@gmail.com> wrote:
>> On 21/02/24 15:06, J.O. Aho wrote:
>>
>>>>>> And it is not important to maintain the same value
>>>>>> as Cygwin, because Cygwin creates PE executables,
>>>>>> while mine is for ELF executables.
>>>>>
>>>>> Are you just trying to keep your Linux source
>>>>> source-compatible with your (Cygwin-based) Windows
>>>>> source? Or are you actually looking for the functionality
>>>>> behind the O_TEXT flag?
>>>>
>>>> The latter. Functionality on PDOS/386, not Linux.
>>>
>>> Think you need to look into the windows source code, as open() already
>>> exists in windows
>>
>> There is no such syscall. kernel32 exports CreateFile.
>>
>> Regardless - Windows won't run the Linux ELF binary -
>> not even the one I produce myself - regardless. Although
>> if you install WSL it would, but that's installing
>> Linux - and of course Linux programs run under Linux.
>>
>> It is PDOS/386 that will run it. And receive the
>> INT 80H. And check for the flag.
>
> so make you library figure out which OS is running and
> remap the flags given to the to open() function call as
> apropriate when translating to int80

Why would anything need to be remapped? Whenever
Linux binaries are run, I use standard Linux
values for everything in every system call. With
one single exception, which is an addition, not
a change - I add the O_TEXT of 0x4000 0000, which
I want ignored on Linux (only), and is indeed
ignored (on Linux).

Anyway, PDOS/386 now runs 32-bit MSDOS (by some
definition), Win32, Linux and OS/2 binaries. A
subset of valid binaries. Enough to run my
toolchain, and use my toolchain to rebuild my
toolchain.

OS/2 still has some gaps in the toolchain though.
I don't have a linker to build OS/2 executables
and I don't have the microemacs editor working
for OS/2 32-bit yet. Both are being worked on
currently.

And none of the executables I produce are dependent
on the registers or stack at entry, which clears
the way to introduce the PDOS-generic ABI, where
instead of DLLs, you are given a pointer to a
structure with callback functions for a C library.

BTW, another development was UC386L, a 50k Linux
executable, with no external dependencies, not
even libc, is capable of running that same subset
of valid Win32 and OS/2 executables.

BFN. Paul.