DOS ain't dead

So I have previously discussed what the definition of "DOS" is - ie if Microsoft had produced a 32-bit version of MSDOS - does that even have a meaning?

In the past I have not liked Unix, although strictly speaking I don't think I've ever used Unix - only Linux, Solaris etc. So I don't know the definition of "Unix" either.

Regardless, PDOS/386 now supports (to a sufficient - depending on needs - extent) Win32, OS/2 2.0, Linux, 32-bit MSDOS and PDOS-generic APIs (all on a 360k floppy).

And as of a few hours ago there is a pdosl.zip (search for "Linux" at http://pdos.org) which contains the toolchain (to build the toolchain and PDOS/386 itself) as 32-bit Linux ELF executables that run on either real Linux or PDOS/386.

I'm now looking into producing my own (minimal) Linux distribution that would be matched to that PDOS/toolchain disk. I already have my own Freedos distribution.

So I'm not sure what the definition of any of DOS, Unix or Linux is, because I've spent a lot of effort to make everything look like MSDOS and it's difficult to detect what any of these things are.

And at the source code level, everything is C90. You can inspect the C library if you want, but that creates a very narrow definition, and still doesn't really help when everything runs (or can run) everything anyway.


EDIT: With both the C library and toolchain in place, I don't think I have an issue with Unix/Linux anymore.

DOS is a "disk operating system". It is an operating system that does the basic I/O functions so that the programs don't need to do those themselves. DOS handles the filesystems and console I/O without restricting what the programs themselves can do.

Most DOS operating systems on x86 have the same standardized ABI as DR-DOS, MS-DOS, FreeDOS and others.

Amiga also has a DOS kernel on its ROM. It does the same things but of course it is not compatible with any DOS on x86. The CPU instruction set is also different.

Unix is the original definition of POSIX. Other POSIX-compliant operating systems are Unix clones. Modern POSIX does a lot more than DOS. POSIX operating systems are (usually) multitasking and they have a standardized API, but no standardized ABI.

API means Application Programming Interface. It is the higher-level "human-readable" interface that is used in calling conventions of C library functions.

ABI means Application Binary Interface. It is the low-level interface that is used by the compiled programs to make syscalls to the kernel.

> DOS is a "disk operating system". It is an operating system that does the
> basic I/O functions so that the programs don't need to do those themselves.
> DOS handles the filesystems and console I/O without restricting what the
> programs themselves can do.
>
> Most DOS operating systems on x86 have the same standardized ABI as DR-DOS,
> MS-DOS, FreeDOS and others.

I refer to systems with this common ABI as 86-DOS systems because they're DOS systems implemented in the Real/Virtual 86 Mode of x86 machines.

---
l

> DOS is a "disk operating system". It is an operating system that does the
> basic I/O functions so that the programs don't need to do those themselves.
> DOS handles the filesystems and console I/O without restricting what the
> programs themselves can do.
>
> Most DOS operating systems on x86 have the same standardized ABI as DR-DOS,
> MS-DOS, FreeDOS and others.
>
> Amiga also has a DOS kernel on its ROM. It does the same things but of
> course it is not compatible with any DOS on x86. The CPU instruction set is
> also different.
>
> Unix is the original definition of POSIX. Other POSIX-compliant operating
> systems are Unix clones. Modern POSIX does a lot more than DOS. POSIX
> operating systems are (usually) multitasking and they have a standardized
> API, but no standardized ABI.
>
> API means Application Programming Interface. It is the higher-level
> "human-readable" interface that is used in calling conventions of C library
> functions.
>
> ABI means Application Binary Interface. It is the low-level interface that
> is used by the compiled programs to make syscalls to the kernel.

Ok, and is FreeDOS considered to be "DOS" then? ie does being ABI-compatible create the definition? API is not enough? What if FreeDOS has a bug, or has a bug fix, or lacks a feature, that makes it not exactly the same as MSDOS? And if a bug in MSDOS 1.0 is fixed in MSDOS 2.0, does that make it not compatible?

Switching to Linux - PDOS/386 supports a subset of the Linux ABI. It would need to contain 100% (or more) of the Linux ABI in order to be called Linux?

I guess you could say that for something to be "DOS" it would need to support the published API of any version of MSDOS. It doesn't matter if it doesn't support undocumented APIs. And bugs and bug fixes are not counted either way.

But Linux is Windows. Or is adding the WINE subsystem not allowed because it's not in the base kernel?

And PDOS/386 is not Linux - it is only a Linux (and POSIX) subset. Although it may support more than Linux 0.01 already. So then what?

> So I have previously discussed what the definition of "DOS" is - ie if
> Microsoft had produced a 32-bit version of MSDOS - does that even have a
> meaning?

IMHO it is very simple:

Dos and windows: mostly based on binary compatibility. Can run EXEs (within limits) of compatible versions. (many 32-bit win9x apps still run 20 years later, we lost 16-bit only due to the 32->64-bit move)

Unix: attempted binary compatibility with IBCS, but that failed to take on outside some major clients. So basically only source based applications only (often with manual modifications due to slightly incompatible headers). Much narrower bandwidth of even that source compatibility through the years, specially if you consider that only out of the box (without manual changes).

This makes them hard to compare. Apples and oranges.

Anyway, if there were a Microsoft 32-bit Dos, I would assume compatibles could run its binary applications and vice versa, analogous to Dos or Windows.

> > So I have previously discussed what the definition of "DOS" is - ie if
> > Microsoft had produced a 32-bit version of MSDOS - does that even have a
> > meaning?
>
> IMHO it is very simple:

I don't think it's that simple.

> Dos and windows: mostly based on binary compatibility. Can run EXEs (within
> limits) of compatible versions. (many 32-bit win9x apps still run 20 years
> later, we lost 16-bit only due to the 32->64-bit move)

Ok. So Windows is DOS.

> Unix: attempted binary compatibility with IBCS, but that failed to take on
> outside some major clients. So basically only source based applications
> only (often with manual modifications due to slightly incompatible
> headers). Much narrower bandwidth of even that source compatibility through
> the years, specially if you consider that only out of the box (without
> manual changes).

And PDOS/386 is now Linux (not Unix).

> This makes them hard to compare. Apples and oranges.

Not really. Once you switch to source compatibility,
C90 programs work anywhere. So everything is everything.

So you may as well not bother talking about that.

Or am I missing something?

> Anyway, if there were a Microsoft 32-bit Dos, I would assume compatibles
> could run its binary applications and vice versa, analogous to Dos or
> Windows.

Ok, that's fine. First - the concept of a 32-bit DOS
does in fact exist. It's not a contradiction in terms,
at least by your definition. And secondly, you are
confirming that it doesn't exist, rather than saying
that Windows is 32-bit MSDOS. Or DOS extenders are.
Those things are important to know.

And then we can guess at what Microsoft would have
created had they so desired.

And then imagine compatibility with that.

So PDOS/386 is a valid clone of 32-bit MSDOS.

It doesn't run 16-bit MSDOS programs, but it
doesn't need to. It's enough to support the
theoretical 32-bit MSDOS API.

BFN. Paul.

> Not really. Once you switch to source compatibility,

Yes. Or if you just declare you must use development tool X only.

But that is not compatibility. You are define a new platform or a new platform (depending on your generated binaries running on the standard editions of dos/windows).

> C90 programs work anywhere. So everything is everything.

That is unix philosophy emulation on other targets. It is more like making a new cygwin.

> So you may as well not bother talking about that.
>
> Or am I missing something?

Yes. That your "switch" is actually a paradigm shift. You add a limitation on applications (c90, though most C compilers now go for C99 compatibility)

> > Anyway, if there were a Microsoft 32-bit Dos, I would assume compatibles
> > could run its binary applications and vice versa, analogous to Dos or
> > Windows.
>
> Ok, that's fine. First - the concept of a 32-bit DOS
> does in fact exist. It's not a contradiction in terms,
> at least by your definition.

> And secondly, you are
> confirming that it doesn't exist, rather than saying
> that Windows is 32-bit MSDOS.

No I didn't. I said Dos and windows were similar in compatibility philosophy, not that they were the same.

> Or DOS extenders are.

The various extenders are their own subtargets, like cygwin is a subtarget of Windows. Binaries from Extender X usually don't work with Y.

> And then we can guess at what Microsoft would have
> created had they so desired.

I think it would have been a commandline like the pre warp OS/2's .

> And then imagine compatibility with that.

Compatibility that they can run eachothers binaries. (and probably 16-bit dos as well, otherwise it wouldn't be a dos in the first place, but a new OS)

> So PDOS/386 is a valid clone of 32-bit MSDOS.

Since the proof of the pudding is running 32-bit msdos binaries on PDOS/386 and vice versa, that is not easy to compare.

> It doesn't run 16-bit MSDOS programs, but it
> doesn't need to. It's enough to support the
> theoretical 32-bit MSDOS API.

As the compatibility test would involve interchangably running actual binaries, that is totally nonsense to me.

And IMHO a 32-bit MSDOS would have run 16-bit binaries, just like win9x and win2000 did. They were still too important at that time.

> > Not really. Once you switch to source compatibility,
>
> Yes. Or if you just declare you must use development tool X only.
>
> But that is not compatibility. You are define a new platform or a new
> platform (depending on your generated binaries running on the standard
> editions of dos/windows).

Is there a typo above? I don't understand regardless. A new platform or a new platform?

> > C90 programs work anywhere. So everything is everything.
>
> That is unix philosophy emulation on other targets. It is more like making
> a new cygwin.

Sure - And that's a good point. Cygwin does indeed mean that "Windows is Unix" as much as Linux is. Given that you are considering source code compatibility.

> > So you may as well not bother talking about that.
> >
> > Or am I missing something?
>
> Yes. That your "switch" is actually a paradigm shift. You add a limitation
> on applications (c90, though most C compilers now go for C99 compatibility)

As opposed to what? At what level is it reasonable to compare source code compatibility? If Linux has some syscall numbers that are different from Unix, and you use one of those syscall numbers in code instead of using a wrapper function - then does that make Linux cease to be Unix? Even at the source code level?

> > > Anyway, if there were a Microsoft 32-bit Dos, I would assume
> compatibles
> > > could run its binary applications and vice versa, analogous to Dos or
> > > Windows.
> >
> > Ok, that's fine. First - the concept of a 32-bit DOS
> > does in fact exist. It's not a contradiction in terms,
> > at least by your definition.
>
> > And secondly, you are
> > confirming that it doesn't exist, rather than saying
> > that Windows is 32-bit MSDOS.
>
> No I didn't. I said Dos and windows were similar in compatibility
> philosophy, not that they were the same.

I didn't say you said they were the same. I said you said the exact opposite.

> > Or DOS extenders are.
>
> The various extenders are their own subtargets, like cygwin is a subtarget
> of Windows. Binaries from Extender X usually don't work with Y.

Ok.

> > And then we can guess at what Microsoft would have
> > created had they so desired.
>
> I think it would have been a commandline like the pre warp OS/2's .

pre-warp? That was OS/2 3.0 or something. It was only 16-bit OS/2 1.0 that only had a command-line, for a very short time.

> > And then imagine compatibility with that.
>
> Compatibility that they can run eachothers binaries. (and probably 16-bit
> dos as well, otherwise it wouldn't be a dos in the first place, but a new
> OS)

Well this is a new definition. You are insisting on 16-bit now.

That's makes 32-bit DOS a contradiction in terms.

You can in fact call Windows 32-bit DOS using that definition.

> > So PDOS/386 is a valid clone of 32-bit MSDOS.
>
> Since the proof of the pudding is running 32-bit msdos binaries on PDOS/386
> and vice versa, that is not easy to compare.

Sure.

> > It doesn't run 16-bit MSDOS programs, but it
> > doesn't need to. It's enough to support the
> > theoretical 32-bit MSDOS API.
>
> As the compatibility test would involve interchangably running actual
> binaries, that is totally nonsense to me.

Sure.

> And IMHO a 32-bit MSDOS would have run 16-bit binaries, just like win9x and
> win2000 did. They were still too important at that time.

I don't think "importance to business" is a technical characteristic.

My question is about technical characteristics. Not commercial viability.

Regardless, I no longer know what you think "32-bit MSDOS" would actually be. As far as I know, Microsoft already did that (using your new definitions), and called it "OS/2" and also called it "Windows".

[SNIP]
> In the past I have not liked Unix, although strictly speaking I don't think
> I've ever used Unix - only Linux, Solaris etc. So I don't know the
> definition of "Unix" either.
[SNIP]
> So I'm not sure what the definition of any of DOS, Unix or Linux is,
> because I've spent a lot of effort to make everything look like MSDOS and
> it's difficult to detect what any of these things are.

Strictly speaking, Solaris is considered a Unix because it traces it lineage to AT&T Unix (https://en.wikipedia.org/wiki/Oracle_Solaris#History). Part of the reason for POSIX (https://en.wikipedia.org/wiki/POSIX) was to ensure source code interoperability for various early UNIX distributions and Linux has long considered POSIX compatibility as part of its goals.

[SNIP]
> I'm now looking into producing my own (minimal) Linux distribution that
> would be matched to that PDOS/toolchain disk. I already have my own Freedos
> distribution.
[SNIP]

Creating a Linux distribution is easier than ever. There's many small Linux distributions. I updated a distribution that boots inside of DOS (https://github.com/lpsantil/doslinux , https://sites.google.com/view/lpsantil/home/dos-subsystem-for-linux-on-a-hp-t5745). There's videos on the subject as well (https://youtu.be/QlzoegSuIzg).

> Creating a Linux distribution is easier than ever.

It wasn't "easy".

> There's videos on the subject as well (https://youtu.be/QlzoegSuIzg).

Thanks for the video. Although it didn't work exactly like that (problems documented in my Discord channel), it got me close enough to stand up my own Linux distro - search for the last occurrence of "Linux" at http://pdos.org

Awaiting feedback from the pdld author as to whether that is good enough for him to proceed with 64-bit ELF support.

> > Creating a Linux distribution is easier than ever.
>
> It wasn't "easy".

Haha. I guess I do say that as someone who is super comfortable building UNIX/Linux software, drivers, and kernels. I started playing with Gentoo (kernel, userland, apps built from source) before moving to CRUX Linux (kernel from source and userland, apps optionally from source) as my main distro 20 years ago. I used to build WINE to rip my DVDs with DVDShrink and the early NVIDIA driver to play Wolfenstein: Enemy Territory on an unsupported Linux like CRUX.

> > > Creating a Linux distribution is easier than ever.
> >
> > It wasn't "easy".
>
> Haha. I guess I do say that as someone who is super comfortable building
> UNIX/Linux software, drivers, and kernels. I started playing with Gentoo
> (kernel, userland, apps built from source)

Started with Slackware '96 on my own system (kernel 2.0.2x or so), though I of course already had 4.2BSD and 4.3BSD experience as an user. Unfortunately, FreeBSD (1.x,2.x) still required SCSI back then, so I ended up with Fat Penguin OS for the IDE support.

"The nice thing about standards is that you have so many to choose from; furthermore, if you do not like any of them, you can just wait for next year's model." -- Andy Tanenbaum

* https://xkcd.com/927/

Not to be overly cynical, but "standards" are usually ignored or only half-implemented. Too expensive, too inefficient, too complex, too weak, too awkward, too old ("irrelevant!"), too new / untested, obscure / not widespread, unneeded, waste of developer time, or just "not invented here" or "we don't care".

* DPMI Standard
* Single UNIX Specification

(Also see the history of ALGOL 68, the successor to ALGOL 60. Disagreements led to ALGOL W and, more notably, Pascal.)

Maybe you consider that obvious, but it's annoying how difficult it is to stick to standards when few people actually care.

> "The nice thing about standards is that you have so many to choose from;
> furthermore, if you do not like any of them, you can just wait for next
> year's model." -- Andy Tanenbaum
>
> * https://xkcd.com/927/
>
> Not to be overly cynical, but "standards" are usually ignored or only
> half-implemented. Too expensive, too inefficient, too complex, too weak,
> too awkward, too old ("irrelevant!"), too new / untested, obscure / not
> widespread, unneeded, waste of developer time, or just "not invented here"
> or "we don't care".

I can remember someone (possibly in comp.lang.c) saying
something regarding C99 - you can be sure that until
*all* of it is implemented I will be using *none* of it.

I guess this is part of the reason why I'm in this forum
in the first place.

The systems are too complicated such that we are in the
movie "Idiocracy" - no-one knows how to maintain it
anymore.

My wife was unable to operate her bank account for about
6 months because the 6-digit SMS wasn't getting through.
From the biggest bank in Australia.

I could have got that through - anywhere in the world -
in 0.2 seconds using a Commodore 64 and a 300 bps modem.

But the only "solution" they had was "try again later"
and "no-one else has reported a problem".

They needed a competent software engineer to trace the
SMS as far as whatever gateway service they were using,
and then get agreement from a software engineer from
that gateway service that they would take charge of the
problem until they had found the breakage point.

But no-one knows or cares.

That is why I am returning to a simpler world - perhaps
not Commodore 64, but at least IBM XT running MSDOS -
and see if it is possible to create an understandable,
maintainable system.

I do want a cleaner 32-bit system though, but the
historical switch was unclean to me. We went from a
simple 16-bit system to a complex 32-bit system
with GUI - skipping a simple 32-bit system.

And I wish to recontest that notion.

For the mass market GUIs and mouses may be fine.

For certain situations volunteering to be a Unix
sysadmin for the rest of your life may be fine.

But for having a personally understandable system,
I remain on DOS. Or something similar to DOS, anyway.

> Maybe you consider that obvious, but it's annoying how difficult it is to
> stick to standards when few people actually care.

And here's something written by someone else:

https://www.quora.com/Why-did-you-leave-software-engineering/answer/Jeff-Sturm-2

"The inmates are truly running the asylum, as the saying goes"


Who do you expect to be doing something about that?

Big Tech has a vested interest in keeping things as
complicated as possible.

The "business model" of most freeware relies on ignoring
bugs and having no pride in work until some sucker comes
along willing to pay full western contract rates for an
unlimited time to fix the issue.


I guess it's a fundamental problem that "no-one cares".
Most people will do the minimum required to keep their
job and that's the end of it.


Regardless - I personally am slowing everything right down.
And plugging away trying to get very basic things to work.

Or even getting agreement on what the very basic things
even are.

This group could well be the place to get things right.

For whatever reason, people are refusing to move off MSDOS.

That's a huge challenge to the status quo, and that's a
bloody good start.

BFN. Paul.

> Not to be overly cynical, but "standards" are usually ignored or only
> half-implemented. Too expensive, too inefficient, too complex, too weak,
> too awkward, too old ("irrelevant!"), too new / untested, obscure / not
> widespread, unneeded, waste of developer time, or just "not invented here"
> or "we don't care".

I would also add to this list "extensible" standards. The best example of this I think is USB. USB has tons of "sub-standards", and nearly all of them have "vendor-specific" sub-categories that lets a vendor do whatever they want but still be considered "standards-compliant".

The most blatant case of this I've come across in USB are the Ethernet devices. There is a USB "standard" (actually, multiple incompatible USB "standards") for Ethernet over USB, but I've only come across one manufacturer (RealTek) whose devices comply with any of the non-vendor-specific portions of standards. None of the other vendors (at least none that I have seen) comply at all, and even the RealTek devices let you switch them into a vendor-specific mode of operation.

Although USB is very ubiquitous, it is far from "universal" or standard.

And I can come up with more examples of this that are not (at least directly) related to computers.

>
> Although USB is very ubiquitous, it is far from "universal" or standard.
>
> And I can come up with more examples of this that are not (at least
> directly) related to computers.

The "universal standard" for the entirety of the universe is to be nonstandard. ;)

---
--
http://glennmcc.org/

> For whatever reason, people are refusing to move off MSDOS.
>
> That's a huge challenge to the status quo, and that's a
> bloody good start.

"The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw

I actually hate that quote. Progress is not eliminating (or marginalizing) all "inferior" tech.

Did you know PowerShell, written in C#, is the default shell on Windows nowadays? Not ancient CMD anymore. It even runs on Linux! (Mac switched to ZSH a few years ago.) Most Linuxes still use Bash (or dash, a modified ash). I forget which *BSD uses pdksh, maybe OpenBSD??

A lot of projects still require GNU Make (not BSD make, not "POSIX"). Just saying, a lot of "portability" is still hampered by the "POSIX shell" (GNU AutoTools), which requires fork(), which is cumbersome to work around. A lot of that was just to avoid a *nix vendor's broken libc. Heck, POSIX was invented to bridge the gap between SYSV and BSD.

It's just a mess. (I should make a different thread about strict "portability".)

> A lot of projects still require GNU Make (not BSD make, not "POSIX"). Just
> saying, a lot of "portability" is still hampered by the "POSIX shell" (GNU
> AutoTools), which requires fork(), which is cumbersome to work around. A
> lot of that was just to avoid a *nix vendor's broken libc. Heck, POSIX was
> invented to bridge the gap between SYSV and BSD.
>
> It's just a mess. (I should make a different thread about strict
> "portability".)

I totally agree about it being a mess. And that's why
I started with MSDOS and only made improvements to do
with different hardware, not changing the software
fundamentals.

However, that then led me to find that almost everything
I want to do can be done in standard C90, or at most
adding ANSI X3.64 on top. Very little required any
extensions - MSDOS or otherwise.

And once I had established that, plus some recent
information, I was able to have another crack at
Linux, which - as noted, has fork() instead of
spawn() so I didn't want to touch it with a barge pole.

However, I was now in a position to at least have
dummy versions of these functions in PDOS/386, and
I discovered that there is a vfork, or:

CLONE_VFORK 0x4000

Where you basically aren't allowed to do anything
other than execute exec().

Which meant that in PDOS/386 I was able to have a
dummy fork/clone.

And basically bring the Linux apps I am interested
in (ie the ones I build myself), back to what I
expect from MSDOS.

Basically I have turned Linux into MSDOS to my
satisfaction.

The other thing that took about 2 decades to resolve
was malloc(). I didn't want to get involved in
brk/sbrk.

However, it turned out there was another way of
allocation memory - ask for a complicated memory
map but then add a "just kidding" parameter to it.

So the Unix/Linux/POSIX joke has been brought to
MSDOS levels of sensibility once you know how to
do it.

Oh yeah - and the mangled stack could be worked
around too. You can ignore it and go to /proc/<pid>/cmdline
instead.

All 3 of those things had been outstanding in PDPCLIB
for 2 decades and then suddenly got resolved a couple
of months ago such that Linux is (or rather - can be)
as simple as MSDOS.

You can use a relatively simple C library (PDPCLIB) to
hide that ugliness too.

So if you want a 64-bit version of MSDOS on any
platform - just use Linux. And follow the C90
standard in the first place.

I haven't yet resolved what to do about those
situations where you want more than C90, ie
directory scanning. MSDOS gets a DTA and then
you use findfirst and findnext INT 21H calls
(4E and 4F). Win32 doesn't use a DTA. POSIX
has another way (opendir). Linux has another
way (getdents). I'm interested in FAT, not
Linux filesystems, so I'm not sure which to
go with (possibly none of them). OS/2 is another
one that could provide inspiration. UEFI too.

All my 8086 apps will be recompiled as NE executables
and work in both PM16 and RM16 (without separate
codepaths), so since I'm recompiling anyway, I can
have a different API. But that doesn't mean I want
a different API. MSDOS functionality would be the
main driver. But not the sole option for API.

Any suggestions?

BFN. Paul.

> I haven't yet resolved what to do about those
> situations where you want more than C90, ie
> directory scanning. MSDOS gets a DTA and then
> you use findfirst and findnext INT 21H calls
> (4E and 4F). Win32 doesn't use a DTA. POSIX
> has another way (opendir). Linux has another
> way (getdents). I'm interested in FAT, not
> Linux filesystems, so I'm not sure which to
> go with (possibly none of them). OS/2 is another
> one that could provide inspiration. UEFI too.

While I understand the reason why ANSI C does not have any sort of directory handling defined for its standard library, I agree that this is a REAL pitty. This prevents me from doing proper directory-relative file inclusion in my 6502 assembler (for this project I restrict myself strictly to the ANSI C standard lib).

> > I haven't yet resolved what to do about those
> > situations where you want more than C90, ie
> > directory scanning. MSDOS gets a DTA and then
> > you use findfirst and findnext INT 21H calls
> > (4E and 4F). Win32 doesn't use a DTA. POSIX
> > has another way (opendir). Linux has another
> > way (getdents). I'm interested in FAT, not
> > Linux filesystems, so I'm not sure which to
> > go with (possibly none of them). OS/2 is another
> > one that could provide inspiration. UEFI too.
>
> While I understand the reason why ANSI C does not have any sort of
> directory handling defined for its standard library, I agree that this is a
> REAL pitty. This prevents me from doing proper directory-relative file
> inclusion in my 6502 assembler (for this project I restrict myself strictly
> to the ANSI C standard lib).

Can you expand on this a little?

If you were on the ANSI committee back in 1989, or even
today, would you have changed that?

Or added it as a separate extension, perhaps the same
as ANSI X3.64?

And if the answer to either of those is "yes", then would
you have anything specific in mind?

Or would you be hoping that another member of the committee
would have a good design?

Thanks. Paul.

> Or would you be hoping that another member of the committee
> would have a good design?

I have no idea if that is any standard, but the Microsoft path handling functions do a decent job.
AFAICS the Watcom library provides the same services.

> > Or would you be hoping that another member of the committee
> > would have a good design?
>
> I have no idea if that is any standard,

I'm happy to make a BTTR standard.

> but the Microsoft path handling
> functions do a decent job.
> AFAICS the Watcom library provides the same services.

That's fine then.

I just had a look at the msged source code, and they use:

#include <dos.h>

and functions _dos_findfirst() and _dos_findnext().


And so if I'm writing a 64-bit Windows program - or
a 64-bit Linux program for that matter - I just use
those functions and rely on a library vendor (me
putting on a different hat) to provide those
functions using whatever underlying mechanism is
required for that system.

And then Linux and Windows become better DOSes.

Sounds fine to me.

>
> #include <dos.h>
>
> and functions _dos_findfirst() and _dos_findnext().


IMO


#include <io.h>
_WCRTLINK extern long _findfirst( const char *__filespec,
                                  struct _finddata_t *__fileinfo );
_WCRTLINK extern int  _findnext( long __handle,
                                 struct _finddata_t *__fileinfo );

should be your choice; _dos_something() is not proper for your holy grail of portability.

> >
> > #include <dos.h>
> >
> > and functions _dos_findfirst() and _dos_findnext().
>
>
> IMO
>
> #include <io.h>
> _WCRTLINK extern long _findfirst( const char *__filespec,
> struct _finddata_t *__fileinfo );
> _WCRTLINK extern int _findnext( long __handle,
> struct _finddata_t *__fileinfo );
>
> should be your choice; _dos_something() is not proper for your holy grail
> of portability.

Ok, thanks for that. So the attribute isn't being provided,
because that has no sense on non-FAT file systems anyway,
and if people want to differentiate based on that, then
hopefully they can find a suitable field in "finddata_t" -
but noting that any such use of an attribute is not portable.

I have another question.

In order to support EBCDIC ANSI X3.64 terminals on a mainframe
(theoretically they could exist, but I created an emulator
to do it instead), I need to know the ESC character. So in all
my code I need to put #define ESC 0x1b for ASCII, and 0x27
for EBCDIC (from memory).

I think this should instead be in a header file, as:

#define ESC_CHAR 0x1b

#define ESC_STRING "\x1b"

rather than burdening the compiler to recognize '\e' or whatever.

Do you agree that this should be in an "extended C90",
along with those findfirst/findnext functions, and
if so, should there be a generic header file called
nonc90.h or something, rather than io.h plus whatever?

Thanks. Paul.

> I have another question.
>
> In order to support EBCDIC ANSI X3.64 terminals on a mainframe
> (theoretically they could exist, but I created an emulator
> to do it instead), I need to know the ESC character. So in all
> my code I need to put #define ESC 0x1b for ASCII, and 0x27
> for EBCDIC (from memory).
>
> I think this should instead be in a header file, as:
>
> #define ESC_CHAR 0x1b
>
> #define ESC_STRING "\x1b"
>
Definitively NO. There is no reason *ever* to have a C90 program output
ESC_CHAR.

What you have probably in mind is something similar to

  switch (terminal_detected())
           {
           case VT_100:
              cursor_up_string = "\x1b[A";
              cursor_down_string = "\x1b[B";
              cursor_left_string = "\x1b[A";
              break;

           case EBCDIC_ANSI_X3.64:
              cursor_up_string = "\x27(J";
              ...





> rather than burdening the compiler to recognize '\e' or whatever.
if your compiler is burdened by this, change compiler.




> Do you agree that this should be in an "extended C90",
NO.

> along with those findfirst/findnext functions, and
> if so, should there be a generic header file called
> nonc90.h or something, rather than io.h plus whatever?
call it PAUL.H or KERRAVON.H or WHATEVER.H

the idea that a single person could set a standard is hilarious.
the idea that YOU could set a standard is more sad than hilarious.



Tom

> > #define ESC_STRING "\x1b"
> >
> Definitively NO. There is no reason *ever* to have a C90 program output
> ESC_CHAR.

It's not a C90 program. It's an ANSI X3.64 program.
THAT is the standard (plus C90).

> What you have probably in mind is something similar to
>
>   switch (terminal_detected())
> {
> case VT_100:
> cursor_up_string = "\x1b[A";
> cursor_down_string = "\x1b[B";
> cursor_left_string = "\x1b[A";
> break;
>
> case EBCDIC_ANSI_X3.64:
> cursor_up_string = "\x27(J";
> ...
>

If you're doing this, then probably "curses" would
be more appropriate to be made a standard.

That's a job for another day.

For now I just want to support ANSI 3.64.

> > rather than burdening the compiler to recognize '\e' or whatever.
> if your compiler is burdened by this, change compiler.

Microsoft C 6.0 was the last version to run on an 8086.
And thus on my Book 8088 (both of them).

I also have a legal copy of Borland C++ 3.1 I think it is.

Which of those either already support \e or can be updated
to support \e?

I'm in the "Dos Ain't Dead" forum for a reason.

> the idea that a single person could set a standard is hilarious.

I'm not? That's why I've been discussing this here for years.
I mentioned "BTTR standard a few days ago".

Regardless, sometimes single people do set standards.
The MZ header starts with MZ because of one guy.
MSDOS 1.0 complied to Kildall's standard.

> the idea that YOU could set a standard is more sad than hilarious.

Whatever dude.

There's not a lot of competition in the DOS world anyway.
Even less in the PDOS world.

BFN. Paul.

> What you have probably in mind is something similar to
>
>   switch (terminal_detected())
> {
> case VT_100:
> cursor_up_string = "\x1b[A";
> cursor_down_string = "\x1b[B";
> cursor_left_string = "\x1b[A";
> break;
>
> case EBCDIC_ANSI_X3.64:
> cursor_up_string = "\x27(J";
> ...
>

Also, this is wrong anyway.

The sequences are the same [A etc - regardless of
EBCDIC or ANSI - you just need to compile on the
appropriate platform - exactly the same as the
characters in "hello world" - they are resolved
to ASCII or EBCDIC by the compiler.

And it has been like that - forever.

The only issue is that there is no \e and ANSI X3.64
uses that character - rightly or wrongly - and I am
using that standard - rightly or wrongly.

BFN. Paul.

* https://en.wikipedia.org/wiki/EBCDIC#Compatibility_with_ASCII

EBCDIC doesn't have the alphabetical characters in uninterrupted sequence anyways. So that's another gotcha to watch out for.

> * https://en.wikipedia.org/wiki/EBCDIC#Compatibility_with_ASCII
>
> EBCDIC doesn't have the alphabetical characters in uninterrupted sequence
> anyways. So that's another gotcha to watch out for.

Yes, I'm aware of that, and the C90 standard has that covered.

And an EBCDIC version of ANSI X3.64 will also need to take
that into account.

E.g. the terminator is given as an ASCII range, but you
will instead need to do a strchr of a buffer containing
those characters to see if it is found.

Or convert from EBCDIC to ASCII for the purpose of
checking.

Up to the programmer to solve that.

My EBCDIC ANSI X3.64 is already working fine - on real
IBM mainframe hardware.

The terminal is emulated of course. Nobody buys real
VT100 terminals anymore either. Which is interesting,
because the cost of a terminal is quite high now if
that's all you want, as you need a PC.

BFN. Paul.

> #include <io.h>
> _WCRTLINK extern long _findfirst( const char *__filespec,
> struct _finddata_t *__fileinfo );
> _WCRTLINK extern int _findnext( long __handle,
> struct _finddata_t *__fileinfo );[/code]

I was thinking - this burdens the library or OS with
the need to do pattern matching (filespec), and
quite possibly not everyone would agree on which
wildcards to use.

In addition, the library would need to make a decision
on whether to match case or not.

On more thing is that it requires fixed space to be
allocated for the resultant data. If this had been
done right from the start, there would be nowhere to
store a long filename, and not enough space to do
so either.

Would it be more appropriate to simply open a directory -
if you want portability anyway - and then let the
library give you the next entry, so the onus is on it
to provide sufficient space? I believe POSIX has an
opendir() which may provide guidance.

I think long filenames would operate in conjunction with
FILENAME_MAX - if a C90-extended platform suddenly starts
returning long filenames - fine, they should have increased
FILENAME_MAX at the same time, so applications are not
affected at the source code level.

Ultimately my interest is in well-behaved programs at the
source code level. Not binary backward compatibility with
everything from CP/M upwards (not that MSDOS 1.0 did that
anyway).

BFN. Paul.

> I was thinking - this burdens the library or OS with
> the need to do pattern matching (filespec), and
> quite possibly not everyone would agree on which
> wildcards to use.
>
> In addition, the library would need to make a decision
> on whether to match case or not.
>
> On more thing is that it requires fixed space to be
> allocated for the resultant data. If this had been
> done right from the start, there would be nowhere to
> store a long filename, and not enough space to do
> so either.

Several OSes (including OberonOS, which had no subdirs) used filenames limited to 32 max chars. (I may also vaguely be remembering ISO 9660 here.) That seems like a good amount for reasonable use, well at least "better" than 8.3. (I guess 160 kb floppies might disagree, but those were quickly upgraded to 360 kb.)