DOS ain't dead

I'm struggling with the omnipresent *nix ecosystem which rules the world. "All the world's a *nix!" They had some great ideas, but it feels like everything must be shoehorned (exclusively) into "*nix or die!" (Of course that's not true, just use Windows! Ugh.)

* https://en.wikipedia.org/wiki/List_of_Unix_commands

* https://www.gnu.org/prep/standards/html_node/Utilities-in-Makefiles.html
> awk cat cmp cp diff echo egrep expr false grep install-info ln ls
> mkdir mv printf pwd rm rmdir sed sleep sort tar test touch tr true

There are many third-party *nix-standard tools that can save time and effort (less bugs), even on lowly or obsolete platforms like DOS (our favorite): DJGPP FTW!

But, like I said, everything seems to be shoehorned into "*nix only!" The Wikipedia article for literate programming (e.g. Knuth's WEB for TeX/Metafont, originally in Pascal) says Knuth was rebuked for not using *nix tools to solve a certain task more simply. It lists his opponent using: tr, sort, uniq, sed, sh. (Disclaimer: McIlroy was the proponent of *nix pipelines and developed diff, sort, join, tr.)

It's weird because everything starts simple but gets progressively more complex. Diff originally outputted to Ed, Patch came later. Ed spun off both Grep and Sed. DOS even had Edlin as a "temporary" solution. Ed also evolved into Ex/Vi and Sam. TECO evolved into Emacs. AWK (very loosely speaking) evolved into Perl and other bigger, more complex, tools.

My opinion: use *nix tools if they can help, if you can download or port them yourself, otherwise write your own simpler replacements. But I don't think it's reasonable to require every system to have a "full POSIX suite" just to rebuild simple things!

> It's weird because everything starts simple but gets progressively more
> complex. Diff originally outputted to Ed, Patch came later. Ed spun off
> both Grep and Sed. DOS even had Edlin as a "temporary" solution. Ed also
> evolved into Ex/Vi and Sam. TECO evolved into Emacs. AWK (very loosely
> speaking) evolved into Perl and other bigger, more complex, tools.

You're not alone!

1) Dunno where I read this, but it's a general problem: If you ask people to improve some "thing", they will (nearly) ALWAYS ADD a feature. But if you give them more time and explicitly say, that removing a feature might also be an improvement, they come up with different ideas.

2) https://brutalist-web.design/
3) At http://felix.plesoianu.ro/web/ read the articles in the section "Writing".

---
Forum admin

Hello Rugxulo,

Well, the way I understand it, autoconf — which is, as you might know, behind most of those ./configure scripts — was created precisely for those situations where the build environment might not have a full-fledged POSIX utility suite. In fact the autoconf documentation explicitly states this as a design goal:

> "The problem Autoconf addresses is that the world is a mess. After all, you are using Autoconf in order to have your package compile easily on all sorts of different systems, some of them being extremely hostile. Autoconf itself bears the price for these differences: 'configure' must run on all those systems, and thus 'configure' must limit itself to their lowest common denominator of features."

Furthermore the page you point to

> * https://www.gnu.org/prep/standards/html_node/Utilities-in-Makefiles.html
> > awk cat cmp cp diff echo egrep expr false grep install-info ln ls
> > mkdir mv printf pwd rm rmdir sed sleep sort tar test touch tr true

is just saying that ./configure script and Makefile should not use any programs outside of the above list. (And of course, they do not have to use all the programs that are in the list...)

Naturally, whether autoconf actually satisfies its original design goal is a bit debatable, but saying that autoconf is trying to "make the whole world POSIX" is, I think, not really a fair complaint.

Thank you!

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

Hello Rugxulo,

Incidentally you might want to compare autoconf's auto-configuration approach with the build logic used by Dennis Vadura's dmake (part of GNUish). The build logic used to build dmake is simpler — but there is no ./configure script (or similar) that can detect the build machine's configuration, and you will basically need to fiddle with the build settings by hand.

Thank you!

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

My complaint was not specifically against AutoConf nor ./configure (although it could be argued that a POSIX shell that requires POSIX-only fork() is perhaps not portable enough to rely upon so much).

My complaint isn't even against POSIX (although some things like m4, required by AutoConf, are weak and underspecified and somewhat unreliable, thus demanding non-portable extensions).

Part of my complaint is that certain projects aren't really "portable" and thus only cater to the obvious Linux or *BSD crowds (and also forcibly Windows, if even, because of marketshare). You know, the projects who are "POSIX only!" and won't even accept working patches (!) for impure hybrid environments like DJGPP.

For example, as nice as GNU Sed is, and how wonderful it is that we have a port at all, they rely heavily on Gnulib. I would prefer the simplicity of Minised instead.

Long story short: my used copy of _Software Tools in Pascal_ (Kernighan, Plaugher) arrived today. Hopefully it'll teach me something.

Hello Rugxulo,

> Part of my complaint is that certain projects aren't really "portable" and
> thus only cater to the obvious Linux or *BSD crowds (and also forcibly
> Windows, if even, because of marketshare). You know, the projects who are
> "POSIX only!" and won't even accept working patches (!) for impure hybrid
> environments like DJGPP.

Well, nah, I think the Gnulib maintainers decided that they are not supporting DJGPP, just because.

For other projects that are not Gnulib, well, my thinking is that developing portable software is always tricky. There is no way to attain portability without testing your software on all the platforms that they should run on.

And this gives rise to another question: why do we have the expectation that some project's source tree should be easily buildable for a wide range of platforms?

Thank you!

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

> Well, nah, I think the Gnulib maintainers decided that they are not
> supporting DJGPP, just because.

I don't think it's "just because". Probably the project want to use some modern API provided by modern unix(like) OS that DOS/DJGPP lacks. It then complicate things when you need to emulate something missing. Also there are some slight differences that grows during years because other systems develops further while DJGPP is frozen for many years and there's very little developers involved so nothing to wonder about...

---
DOS gives me freedom to unlimited HW access.

> > Well, nah, I think the Gnulib maintainers decided that they are not
> > supporting DJGPP, just because.
> I don't think it's "just because". Probably the project want to use some
> modern API provided by modern unix(like) OS that DOS/DJGPP lacks. It then
> complicate things when you need to emulate something missing. Also there

Except that one of Gnulib's goals is to be that portability emulation layer ("Gnulib is intended to be the canonical source for most of the important `portability' and/or common files for GNU projects").

Which means that, basically, the Gnulib maintainers decided that DJGPP is so hard — or obscure, etc. — to port software to, that they do not want to create a portability layer for it. And they have every right to make that decision, of course.

Thank you!

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

> Except that one of Gnulib's
> goals is
> to be that portability emulation layer ("Gnulib is intended to be
> the canonical source for most of the important `portability' and/or common
> files for GNU projects").

Probably it needs some minimal support of system to be ported. Someone may want it would be ported e.g. to C64 or ZX Spectrum or ATmega or ENIAC... but it may not provide minimum requirements to make the port for reasonable effort, esp. where there are very few users (weak effort/benefit ratio). (I didn't investigated how really hard it would be to make DJGPP port)

---
DOS gives me freedom to unlimited HW access.