Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ivan Shmakov <ivan@siamics.netREMOVE.invalid>
Newsgroups: alt.os.free-dos,comp.misc
Subject: FreeDOS caveats
Date: Thu, 25 Apr 2024 18:42:02 +0000
Organization: Dbus-free station.
Lines: 271
Message-ID: <MWayucb32sgc0oNH@violet.siamics.net>
References: <slrnv2aagh.2fm.bencollver@svadhyaya.localdomain>
Injection-Date: Thu, 25 Apr 2024 20:43:00 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="cb905a80a3fc58390ffb47347e30b5dc";
	logging-data="3323626"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/nA65/8UnxBvhOqBfgHk3a"
Cancel-Lock: sha1:GQSglc83brsSrZaQ9qrsm70mTJo=
License: CC-BY-SA-3.0+ (original contributions only)
Bytes: 13838

	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.)

========== REMAINDER OF ARTICLE TRUNCATED ==========