O_TEXT

[Paul Edwards]

Some operating systems like MVS present a whole
block of a block device to the application (thus
C library), and the C library is responsible for
sorting things out. Unix instead converts that
into a byte stream for you.

Similarly, it seems that almost everyone expects
the application, thus C library, to be responsible
for getting the line endings of text files correct.

There is one exception that I know of, sort of,
which is Cygwin, which has this in fcntl.h:

/* For machines which care - */
#if defined (_WIN32) || defined (__CYGWIN__)
#define _FBINARY 0x10000
#define _FTEXT 0x20000
#define _FNOINHERIT 0x40000

#define O_BINARY _FBINARY
#define O_TEXT _FTEXT
#define O_NOINHERIT _FNOINHERIT


Now when I am running a Linux ELF binary on PDOS/386,
I would prefer that it "fits in" with the rest of the
system and gets CRLF endings. Basically the same as
Cygwin.

For that to work I need the open syscall to carry the
text/binary information. Binary is the default, so I
just need a text flag.

Is there a suitable bit I can use?

There seems to be lots of things currently in use
(here are some):

#ifndef __O_LARGEFILE
# define __O_LARGEFILE 0100000
#ifndef __O_DIRECTORY
# define __O_DIRECTORY 0200000
#ifndef __O_NOFOLLOW
# define __O_NOFOLLOW 0400000
#ifndef __O_CLOEXEC
# define __O_CLOEXEC 02000000
#ifndef __O_DIRECT
# define __O_DIRECT 040000
#ifndef __O_NOATIME
# define __O_NOATIME 01000000
#ifndef __O_PATH
# define __O_PATH 010000000


I don't know what those are, and I don't know if
there are spare bits that won't cause an issue.

Another possibility would be to have a combination
of bits, perhaps an unusual combination, like I
assume switching off the access time above, and
that will be a hint that it is actually a text
mode file. So on Linux access times are no longer
a thing for any application I produce - but I don't
care about that. What I care is that PDOS/386 has
an opportunity to insert CRs.

Any suggestions?

Thanks. Paul.

[Paul Edwards]

Post by Paul Edwards
#define _FTEXT 0x20000
#define O_TEXT _FTEXT

I ended up going with 0x4000 0000 so that I
could reserve 0x8000 0000 to mean "we have
run out of bits, check xyz extension variable
instead".

And it all works - I can run (certain) Linux ELF
executables on PDOS/386. Including microemacs 3.6.

Also I added OS/2 support in a similar but not
identical manner. That runs C90 apps now (ie
certain OS/2 LX executables), but fullscreen
support is still pending on a couple of things.

In all cases, I am no longer dependent on
registers or stack on entry to the executable,
which clears the way for all executables to
be called with the PDOS-generic stack "standard".

I previously mentioned that I had UC386L, a 53k
Linux executable capable of running a subset of
valid Win32 executables.

I think because I eliminated memmgr, it is still
53k, but now runs the OS/2 subset as well.

BFN. Paul.

[Paul Edwards]

Post by Paul Edwards
In all cases, I am no longer dependent on
registers or stack on entry to the executable,
which clears the way for all executables to
be called with the PDOS-generic stack "standard".

I managed to get this to work today.

So now PDOS/386, which fits on a 360k floppy, supports
C90-compliant programs for any of of the following
systems (if they are built "correctly" (TM) - a
term that I made up):

1. 32-bit MSDOS (sort of - since the original didn't exist)
2. Win32
3. Linux
4. OS/2
5. PDOS-generic

Using different methods of implementation.

1 and 3 are done by servicing the interrupts
(mainly INT 21H and INT 80H)

Win32 intercepts the C library MSVCRT

OS/2 intercepts the OS/2 system calls at
the DLL interface (doscalls.dll)

PDOS-generic passes the callback functions as
a stack parameter.

BFN. Paul.