On Wed, 24 Apr 2024 14:30:10 -0000 (UTC), candycanearter07 wrote:

> The option is kinda hidden in the Device Manager.

Why is it an “option”, in this day and age?

On Wed, 24 Apr 2024 12:32:11 -0000 (UTC), John McCue wrote:

> ... I hate VMs ...

You hate tools which were invented specifically to make it easier what you
would like to do?

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 22:21 this Wednesday (GMT):
> On Wed, 24 Apr 2024 14:30:10 -0000 (UTC), candycanearter07 wrote:
>
>> The option is kinda hidden in the Device Manager.
>
> Why is it an “option”, in this day and age?

Tradition, probably.
--
user <candycane> is generated from /dev/urandom

On Wed, 24 Apr 2024 22:20:58 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Wed, 24 Apr 2024 20:07:25 +0100, Kerr-Mudd, John wrote:
>
> > Be more explicit that we are not maintaining the x86 version anymore
>
> Notice the versions they *are* maintaining?

No I didn't; all my computers are x86.

--
Bah, and indeed Humbug.

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.

On 2024-04-25, Ivan Shmakov <ivan@siamics.netREMOVE.invalid> wrote:
> Corrections and constructive criticism are of course welcome.

It looks as though some effort was put into composing this message.
Nice work, assuming it is human generated.

Do you seriously think that vim 7.3 is going to reformat your flash
drive?

I don't think DOS is a supported platform for vim any more, so
unless someone steps up to the plate, there never will be a newer
version than 7.3. FreeDOS is the wrong platform for anyone for whom
that will be a deal breaker.

It's the right platform for someone who would enjoy that challenge,
or for someone who can deal with dead/stable software. One could also
opt for an editor that IS still supported on DOS, such as sved or xvi.

On Thu, 25 Apr 2024 14:30:13 +0000, candycanearter07 wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 22:21 this Wednesday
> (GMT):
>> On Wed, 24 Apr 2024 14:30:10 -0000 (UTC), candycanearter07 wrote:
>>
>>> The option is kinda hidden in the Device Manager.
>>
>> Why is it an “option”, in this day and age?
>
>
> Tradition, probably.

Backwards compatibility. It's what the majority of users are used to.

But Lawrence has to pursue his agenda.

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

On Thu, 25 Apr 2024 19:09:58 +0100, Kerr-Mudd, John wrote:

> On Wed, 24 Apr 2024 22:20:58 -0000 (UTC) Lawrence D'Oliveiro
> <ldo@nz.invalid> wrote:
>
>> On Wed, 24 Apr 2024 20:07:25 +0100, Kerr-Mudd, John wrote:
>>
>> > Be more explicit that we are not maintaining the x86 version anymore
>>
>> Notice the versions they *are* maintaining?
>
> No I didn't; all my computers are x86.

There’s a RISC-V emulator (both 32-bit and 64-bit) available, just an
“apt-get install qemu-system-misc” away. You could try that at essentially
no cost <https://packages.debian.org/bookworm/qemu-system-misc>.

Kerr-Mudd, John wrote:

>> A promising alternative was MS DOS 5's "DOSShell" program, but that go
>> killed off to save Windows sales.
>
> DOS 4.0, sorry.

Is that included in yesterday's MS-DOS 4.0 source code release?

<https://cloudblogs.microsoft.com/opensource/2024/04/25/open-sourcing-ms-dos-4-0/>