DOS ain't dead

So you're probably already familiar with Cygwin
adding an O_TEXT extension for Unix programs
so that when run under Windows the CRLF can be generated.

I have done the same thing with the Linux executables
I produce (by linking with PDPCLIB):

/* reserve 8000 0000 as a flag to indicate extension */
/* make sure O_TEXT hasn't been set to 0 by undefining */
/* and next available bit counting down is thus 4000 0000 */

#undef O_TEXT
#define O_TEXT 0x40000000

static int open(const char *a, int b, int *c)
{
int ret = -1;
int oflag = 0;

if (myfile->textMode)
{
oflag = O_TEXT;
}


And now I wish to do something similar with MSDOS open (21H 3DH).

https://www.ctyme.com/intr/rb-2779.htm


And this:

https://www.ctyme.com/intr/rb-2779.htm#Table1402

3 reserved (0)


looks like the most likely candidate. But as with Linux above,
I want to allow for more flags to be added. And it looks to
me like they are all in use (table 1402).

So what I would suggest is that bit 3 doesn't mean "O_TEXT",
it instead means "check register cx for more flags", and
then bit 0 of CX can mean O_TEXT.

Note that this is a more general question than just MSDOS.

Because I have the Pos wrappers, I actually call PosOpenFile,
which looks like this:

int PosOpenFile(const char *name, /* func 3d */
int mode,
int *handle);

So it is probably best for me to create a mode2 parameter
for the extended flags.

Although another option is to use the top 8 bits of the
existing mode parameter as the first 8 bits of the CX
extension.

However the spirit of the Pos functions was to match
directly onto the MSDOS registers.

Any thoughts on a "BTTR standard"?

Microsoft obviously don't care so it may as well be
BTTR that is the defacto "steering committee".

Thanks. Paul.

Oh - I forgot to mention.

I previously mentioned that I created what I
consider to be a "port of MSDOS to the mainframe".
You can see that - zpg.zip at pdos.org

Well, it is working, but when I use the mfemul.exe
mainframe emulator, I would like to be able to go:

type temp.txt
(to access the EBCDIC FAT32 disk)

and:
type :temp.txt
(to access temp.txt on the host system, which will
be in ASCII)

So the program (pcomm/command.exe/com) that converts
the "type" command into an fopen with "r" (not "rb"),
needs to have that "r" (text mode) status carried
all the way through so that mfemul knows that it needs
to do an ASCII to EBCDIC translation in the process.

It's not just about CRLF vs LF as in Cygwin. It's now
about ASCII to EBCDIC conversion *as well*.

BFN. Paul.

Hello kerravon,

Actually, O_TEXT and O_BINARY seem more and more like a rather inelegant (if practical) hack to me these days. I now think the Newlib library has the right idea: have read (...) and write (...) always return raw binary data, and convert between LF and CRLF at one and only one layer: at the stdio level (fopen, fread, fwrite, printf, scanf, etc.).

I think the only reason O_TEXT and O_BINARY exist is that some programs use read and write, and assume that the data handled by these routines contain Unix-style newlines. The more correct way to get these programs to work on DOS, is probably to rewrite these programs to read/write text files via stdio, but I realize this may not always be practical.

Meanwhile, int 0x21, ah = 0x3f or 0x40 have always dealt with raw bytes, and continue to do so.

So... I would advise against modifying the raw system calls (i.e. int 0x21, ah = 0x3f or 0x40) to do any sort of encoding conversion. Having LF ↔ CRLF conversion potentially happening at any and all of the 3 interface layers (machine syscall, POSIX routine, stdio) sounds like a recipe for chaos. But you do you.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> I think the only reason O_TEXT and O_BINARY exist
> is that some programs use read and write,
> and assume that the data handled by these routines contain
> Unix-style newlines. The more correct way to get these programs to work on
> DOS, is probably to rewrite these programs to read/write text files via
> stdio, but I realize this may not always be practical.

I'm a bit naive. I've never used creat (which GCC IA-16 lacks, see mininasm) or read. I guess they are always available on POSIX systems. (Mininasm used them for much lower footprint, and TurboC and OpenWatcom had no problems.)

creat (HelpPC)

quoting fopen (again, HelpPC):

> - text mode input, will have CRs discarded
>
> - using any of the stdio functions results in a default allocation
> of 512 bytes for the I/O buffer and the inclusion of the standard
> memory allocation functions

Thanks for your thoughts.

What I can do is create additional Pos* calls, so
that instead of fopen() calling PosOpenFile() which
gets translated into the MSDOS interrupt, I can
instead get fopen() to call PosFopen() which has
identical parameters. And then gets translated into
an MSDOS extension (the same way that MSDOS 7 is an
extension of MSDOS 2).

Given that Microsoft is no longer extending MSDOS,
it's free for anyone (ie bttr or whoever) to extend
MSDOS.

But the definition of "MSDOS" gets hazier and hazier
in that process.

BFN. Paul.

I get this:

Error!
A database error has occurred.


When posting this:

> Having LF (funny character here) CRLF conversion
> potentially happening at any and all of the 3 interface layers (machine
> syscall, POSIX routine, stdio) sounds like a recipe for chaos. But you do
> you.

> do any sort of encoding conversion. Having LF XXXXXX CRLF conversion
> potentially happening at any and all of the 3 interface layers (machine
> syscall, POSIX routine, stdio) sounds like a recipe for chaos. But you do
> you.

How come the original was able to be posted?

Hello kerravon,

> identical parameters. And then gets translated into
> an MSDOS extension (the same way that MSDOS 7 is an
> extension of MSDOS 2).

Well, that sounds like an idea.

Fun fact: some configurations of MS-DOS actually allow the backslash character code (0x5c) within a filename.
Under DOS/V (Japanese), a 0x5c byte may occur as part of a double-byte character code.
Some time back I tweaked my libi86 library to handle such cases.

Another fun fact (just discovered): MS-DOS apparently has some support (?) for using an EBCDIC character set as its global code page (via int 0x21, ax = 0x6602).
I am not sure how exactly it works though.
I suspect -- as with DOS/V -- this support is mainly useful for dealing with oddball character sets in file names.

> How come the original was able to be posted?

I used a HTML entity code to enter the double arrow.
I suppose the forum still has a bit of a problem dealing with some Unicode characters.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"