FreeDOS caveats

Being partial to DOS-era games, I've adopted FreeDOS for my
Am386-based gaming box, which I also occasionally use for
other purposes (such as taking notes or listening to .mod /
.rad / etc. music.)  So I suppose I can add my $0.02 to the
thread as well.

The advantages of using such a setup are pretty obvious:

* it's a system you can, with reasonable effort, get to know
  very much inside-out; it's simple and stable enough that
  it won't surprise you with a sudden change of, say, its
  init system (if only for the reason that it doesn't have
  any to speak of in the first place);

* it can run on older hardware that you either already have
  or can get for little to no cost; it won't require you to
  shop for newer hardware, ever, not even when you decide to
  upgrade to a newer version;

* there's a decent selection of reasonably lightweight
  software, written over the decades of DOS existence.

Nevertheless, for the reasons I'll try to elaborate
upon below, it's by no means a perfect solution for every
concievable use case.  I hope it doesn't come off as
discouraging, but I believe than one looking to make use
of FreeDOS is better to have an idea of the obstacles they
might face.

Corrections and constructive criticism are of course welcome.


First and foremost, FreeDOS doesn't seem to have much manpower
behind it.  Some of its software was ported, rather than
written from scratch, and going by the listing.gz [1] file,
some of the ports lag behind the latest upstream versions.
For example, of the software I use both in and out of FreeDOS,
the latter's versions are:

vim 7.3a - Improved version of the "vi" editor
lynx 2.9.0-dev.10r2 - Lynx text and graphics WWW browser

[1] http://ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest
    /listing.gz (URI split for readability.)

For comparison, on my Debian "Bookworm" (current stable)
install, I have those at versions 9.0.1378 and 2.9.0-dev.12,
respectively.  And while I'm hardly in the habit of chasing
latest software features, I /do/ interact with the outside
world, and as such, prefer to use software that is /maintained/
at least for security issues.

And despite of how unlikely this is to happen in practice,
I'd hesitate to open a random .txt file with FreeDOS' Vim for
the concern that such an old version might have an unfixed
bug that'll cause it to, say, format my SSD (CF) C:.

This is also a more pressing concern for FreeDOS than it'd
be for a multiuser system, as not only it lacks the concept
of user privilege separation, it also doesn't separate user-
and kernel-spaces.  Attempting to access the IDE controller
directly on a Unix-like x86 system outside of the system's
kernel code will earn you SIGSEGV (or similar); not so in
FreeDOS.


Now, FreeDOS is a volunteer-driven effort anyone can contribute
to, so the manpower issue is something the community, in
principle, /can/ fix.  There's a catch, though.  If you're
familiar with, say, NetBSD, you might expect to install GCC
and tools, unpack the sources, patch them as strikes your
fancy, run $ make, and have the system built.

Won't be as simple with FreeDOS, alas: a lot of the software
there was developed by volunteers over the course of decades,
and often using whichever development tools the particular
developer has had at hand.  The system appears to supply a
plenty of compilers currently, such as DJGPP (DOS GCC x86-32
port), Open Watcom C/C++, IA-16 GCC fork, and Bruce's CC...
and yet you might stumble upon individual packages that
require Turbo C, or Turbo Pascal, to build.


One another issue is hardware compatibility.  As a somewhat
"out of left field" example, one of my IRC pals [*] is living
off-the-grid and hence during the winter, about the only
computer they can run within their solar energy budget is an
outdated Android tablet.  Quite obviously, they can't run
FreeDOS there, and neither can they replace it with some
random off-the-shelf FreeDOS-compatible machine, for power
consumption reasons alone.

[*] I'm currently on a break from most of my usual IRC channels,
    but you can still find me on several low-traffic ones, such as
    irc://irc.efnet.org/%23coders .

Most of the systems it'd be reasonable to run FreeDOS on are
only available second hand, and those come with reliability
implications.  If your DOS box breaks, it's unlikely you'll
be able to replace it with the same model and make.  Older
systems (up to about Pentium-class) are more of a collector's
item at this point, and are probably overpriced as such.

Newer systems will be cheaper, but will have their newer
idiosynchrasies, and incompatibilities as well; such as:

* system-wide drivers were more of an exception in DOS
  software; you can run, say, Wolfenstein 3D on a relatively
  recent x86 box, but the chances are that it won't have a
  SoundBlaster-compatible audio card installed (on account
  of most of those being ISA-based, and general purpose
  mainboards haven't been equipped with ISA slots for some
  15 years now); and it's one of the few ones the game
  supports; same goes for audio players;

* another particular example is USB support, or the effective
  lack thereof; sure, FreeDOS will support whichever keyboard
  is supported by BIOS, and depending on the BIOS version,
  that might include USB keyboards; other than that, I've had
  some success running usbdos.zip, but it only supports UHCI,
  and the use of such chips was apparently shortlived; I've
  only found one on an AGP-enabled "i686" box; furthermore,
  my understanding is that FreeDOS will only support the USB
  mass storage device it's booted from (yet again, so far as
  BIOS supports it), while flash drives attached while
  FreeDOS is running won't be accessible;

* NIC packet drivers are somewhat of an exception: even
  relatively recent NICs might have DOS-compatible drivers
  available; they might be proprietary, though, and as such,
  not part of FreeDOS;

* another issue is that, as a rule, DOS software doesn't make
  use of the x86 HLT instruction, and thus it will keep the
  CPU core it runs on busy all the time (FreeDOS core
  components are an exception, though: if all you want to run
  is COMMAND.COM, it /will/ use HLT as appropriate, provided
  you have IDLEHALT=1 in your FDCONFIG.SYS); it wasn't much
  of an issue for 386-class CPUs, but on more recent hardware,
  it might make quite a difference, whether to your battery
  time, or to your utility bill;

* the same applies to running FreeDOS under a virtual machine:
  your idling good old text editor might be usable on a 286,
  but it will still happily take 100% of one of your system's
  GHz cores when run under QEMU.

One of the rather few alternatives I'm aware of are weeCee
(e. g., [2, 3]), which is a reasonably compact DOS-compatible
machine with a CS4237-based SoundBlaster-compatible audio.

[2] http://vogons.org/viewtopic.php?t=80651&start=580
[3] http://en.wikibooks.org/wiki/History_of_video_games/Platforms/weeCee

If you're interested in running DOS software (rather than
a full standalone DOS system), the obvious choice is DOSBox.
As it inherently limits the amount of CPU cycles available
to guest software, the lack of HLTs is less of a problem.
However, it doesn't aim to offer as good /isolation/ as,
say, QEMU, so you might want to run it under a separate user
account, lest DOS malware tamper your host system $HOME.


For those curious, the following are specific issues I've
noticed over the years of using FreeDOS.

There're a few free (as in "free software") programs that I
think should've been included in the distribution, but aren't.
There's LDPCXTGA simplistic .pcx / .tga image viewer [4], and
there're SBMIX and ISAPNP packages [5, 6] that are essential
if your sound card is a software-configured (ISA PnP) one
(see, e. g., [7].  Granted, there's sound/sbpmixer.zip in [1],
now; no idea how it compares to SBMIX.)

[4] http://archive.org/download/simtelnet_bu_mirror_2013_04
    /simtelnet.bu.mirror.2013.04.zip/simtelnet%2Fmsdos%2Fgraphics
    %2Fldpcxtga.zip (URI split for readability.)
[5] http://roestockfox.co.uk/isapnptools/index.html
[6] http://bttr-software.de/products/sbmix/
[7] news:20220624105031.m6wk4sa7ztce6lkm@violet.siamics.net
    http://al.howardknight.net/?STYPE=msgid
    &MSGI=%3c20220624105031.m6wk4sa7ztce6lkm@violet.siamics.net%3e
    (URI split for readability.)

On the topic of sound, the OpenCP player chokes on some ID3
tags in .mp3 files.  (It's also too heavy on the CPU to be
of any use on a 386; though it does run well on a Pentium.)

The Adplay player included doesn't support some of the
formats (presumably those introduced after its last update in
2007) and also seems to have stability issues.

The FreeDOS kernel does have FAT32 support (unless I'm
misremembering: my primary FreeDOS box uses FAT16 / ECMA 107
for its 128 MB SSD), yet FreeDOS DEFRAG doesn't.

As to networking, it bears to mention that while a DOS packet
driver is a resident (TSR) program, the TCP/IP stack is a
library (+ support tools), statically-linked into a given
application.  The traditional choice for such a library was
the Waterloo TCP (WATTCP) package.  It is used by the FreeDOS
build of Lynx, among others.  A newer (and, at a glance,
better / maintained) such package is mTCP.  It comes with
such tools as PING, IRC and SNTP clients, and an HTTP/1 server.
Naturally, these packages / libraries each use their own
configuration files, which is potentially confusing.
Worse still, neither supports IPv6, which is a sure downer
for a /64 network operator and a networking amateur I am.
(I have a distinct recollection of being able to successfully
configure and use at least some parts of the picoTCP package,
but somehow, it's an experience I wasn't able to recreate.)


Lastly, on the alternatives.  FreeDOS is a decent choice for
those intending to put their 8088- .. 80386-class systems to
good use.  There's not much alternative even on Pentium-class
hardware when you're aiming to run (non-free) DOS-era software
on the box, such as games.  (Though it should be noted that
some of the popular DOS games /do/ have free software ports /
clones; there's Chocolate Doom that aims to be very faithful
to the original, Tyr Quake, and much extended but still very
much in the same vein OpenTTD.)

If DOS-era software is not a concern, there's a Unix-like
ELKS system you can try instead on 8088- and 80286-class
hardware.

From 486DX onwards, it becomes possible to run NetBSD instead.
(Other *BSD systems might also support such hardware; NetBSD
is the only *BSD I'm personally familiar with.)

In case you have interest in OS development, and specifically
in exploring implementing OS internals in unconventional ways,
you can probably give GNU/Hurd a try.

Outside of x86, if you're looking for an embedded platform,
the 8-bit AVR MCUs are perhaps somewhat limited and costly,
but they're old enough to have good support from free software
development tools.  Say, I was able to write a test suite for
the AVR firmware I've been developing in Perl (with Test::More)
and run it against said firmware loaded into the Simavr
emulator.  Once debugged, it ran the same on the real MCU.

Then there's Z80 and CP/M.  The latter was re-released under
a free software license a while back, though the terms were
somewhat vague until the copyright holder clarified them
several years ago.  The hardware to run a CP/M install will
perhaps be even harder to come by, but Z80 reportedly has
considerable support from free software development tools
(check SDCC and z80pack, for instance.)

For STM32 and the like, there's Contiki-ng.  It does come
with a TCP/IP stack, though in this day and age, networked
computers are probably better to support strong encryption
and remote SSH access to facilitate security upgrades and
emergency configuration tweaks.

Which in turn leads us to 64-bit ARM-based SBCs running the
aforementioned NetBSD, or GNU/Linux (see, e. g., [8].)
Sure, this thread was started [**] on the observation how one
doesn't need Chromium and Gnome and whatnot and can use FreeDOS
instead, but the point is: you don't need Chromium and Gnome
and whatnot even if you /don't/ use FreeDOS.  For an example,
I use Lynx as my primary Web UA, and I've been ignoring DEs
for about as long as I've been using GNU/Linux.

[**] I'm exaggerating.
[8] http://wiki.debian.org/CheapServerBoxHardware

--
FSF associate member #7257  np. My heart yearns for you by Joseph Nimoh