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/>

>>>>> On 2024-04-25, Ben Collver wrote:

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

When working time and again as a part-time university
lecturer, I'd typically feed bits of my students' works to
Duckduckgo to detect plagiarism. Makes me wonder if this
approach can be adapted for detecting AI-generated texts.

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

I didn't seriously think that an xz-utils upgrade would
compromise my SSH setup, and it still happened. (Or would
have happened, were I to have any Debian testing installs,
as was my intent.)

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

JFTR, I think I'd be fine with Vim 7 so long as it's
maintained. I'd probably be able to contribute to the
effort, too; just not a task I'd try to pull all by myself.

> It's the right platform for someone who would enjoy that
> challenge, or for someone who can deal with dead/stable software.

That's one of my points: depending on what you're aiming
at, using FreeDOS might come with its own set of challenges,
including software- and hardware-related ones.

For instance, it took me some time to get a working multi-IO
card for my Am386 (though perhaps the issue was with me
misinterpreting the silkscreen configuration reminders and
configuring the jumpers the wrong way on the card I did have.)

Then I had to replace the dead onboard 3.6 V NiMH rechargable
battery; I was unable to find an exact replacement so had to
use a 1 F 5.5 V supercap instead. (It does hold the CMOS
settings awhile, but the RTC stops within 24 hours of the
machine being powered off.)

The old "AT" PSU had a faulty 80 mm sleeve bearing fan. It also
had to be replaced, with a ball bearing Jamicon JF0825B-
something. (Given my prior experience with such fans, I'd
expect it to outlast the PSU itself.)

Then there was the issue of my CompactFlash drive having no
CHS geometry data on the label, and the 386 BIOS not having
the IDE HDD autodetection code, either; solved by plugging
the card into a Pentium box and copying the autodetection
results from there.

Supposedly weeCee is runnable off an SD card (SDHC, I hope),
but my understanding is that it's only available in what's
effectively a "kit": you'll need to do the soldering yourself
if you're going to go that way.

> One could also opt for an editor that IS still supported on DOS,
> such as sved or xvi.

I can't say I'm aware of many Vi-like editors for DOS.
If there's a list somewhere (other than the already mentioned
FreeDOS' listing.gz), I'd appreciate a pointer.

FreeDOS comes with a build of Elvis from 2003, and on the
one hand, it seems workable (I don't use /that/ much of the
Vim functionality; I mostly rely on the vim-tiny build from
Debian, http://packages.debian.org/stable/vim-tiny ), though
I do recall having trouble finding alternatives to some of
the things I came to take for granted with Vim.

On the other hand, it doesn't seem to be maintained, either.

--
FSF associate member #7257 np. HTTP by Master Boot Record

In article <MWayucb32sgc0oNH@violet.siamics.net>,
Ivan Shmakov <ivan@siamics.netREMOVE.invalid> wrote:
> 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.)

I'd think that vintage hardware is still somewhat readily available. In
addition to that, you could build a working system from new parts even
today. There is a minor catch, though: the Z80 is about to go out of
production ater the better part of 50 years:

https://www.mouser.com/PCN/Littelfuse_PCN_Z84C00.pdf

Can't say I did anything with CP/M back in the day other than booting it
once or twice on an Apple II with a Softcard clone, but I stumbled across
the RC2014 a while back and thought I'd try building a system from scratch
that way.

https://gitlab.alfter.us/salfter/rc2014-compat

So far, I've assembled the z80-cpu and paged-rom-ram-1mb boards. The
z80-cpu board uses the Z84C0010AEG running at 10 MHz. So far, I've tested
it by hard-wiring a NOP on the data bus, which causes the address bus to
cycle through its entire range...basically, the CPU is turned into a 16-bit
counter. :) I'm in the middle of assembling the 68b50-dual-serial
board...had to stop the other evening when I found one of the parts I'd
ordered was in the wrong package because the DigiKey part number I'd used
was off by one.

There's a CP/M image available for these that can run from ROM, if you have
enough of it. The board I've built has 512K of flash memory, which can be
paged into the CPU's address space in 16K chunks. 1 MB of SRAM can be paged
in similarly.

(I also ran across a way to put the 6502 onto the RC2014 bus that is
implemented in the 6502-cpu board. I've not built it yet, but I definitely
have more familiarity with the 6502 and will get around to it eventually.)

--
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

On 2024-04-26, Andy Burns <usenet@andyburns.uk> wrote:
> 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/>

No, dosshell is not included. Nor is gwbasic, himem.sys, nor
xmaem/xma2ems.

On 2024-04-26, Andy Burns <usenet@andyburns.uk> wrote:
> 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/>

How Not To Release Historic Source Code
=======================================
Posted on April 26, 2024 by Michal Necasek

This is how to not do it:

GitHub
<https://github.com/microsoft/MS-DOS/tree/main/v4.0>

Don't get me wrong, it's absolutely brilliant that Microsoft was able to
release a fairly complete (minus DOSSHELL) source code for MS-DOS 4.00
or 4.01 (see below). As much as it was hated, DOS 4.0 was an important
milestone and DOS 5.0 was much more similar to DOS 4.0 than not. This
source code will be an excellent reference of modern-ish DOS until
Microsoft officially releases the long ago leaked MS-DOS 6.0 source
code. The source code includes all required build tools, which makes
building it (compared to many other source releases) extremely easy.

But please please don't mutilate historic source code by shoving it into
(stupid) git.

First of all, git does not preserve timestamps, which causes
irreversible damage. Knowing when a source file was last modified is
valuable information.

Second of all, the people releasing the source code clearly thought,
hey, it's source code, let's shove it into git, what could possibly go
wrong. Well, this is what could go wrong:

Nope, not building
<http://www.os2museum.com/wp/wp-content/uploads/2024/04/
dos40src-error1-640x356.png>

For practical purposes, old source files are not text files. They are
binary files, and must be preserved without modification. It is not OK
to take an old source file and convert it to UTF-8. For one thing, UTF-8
didn't even exist in the times of MASM 5.10 and Microsoft C 5.1, of
course old tools can't deal with it!

The above problem was most likely caused by taking a source line using
codepage 437 characters and badly converting them to UTF-8. That made
the source line too long, past the circa 512 byte line length limit of
MASM.

In the case of getmsg.asm it's easy enough to manually delete the too
long line in a comment. But it's much worse with the src\SELECT\USA.INF
file. Here, the misguided use of git not only made some comment lines
too long for MASM, but it also actively destroyed the original source
code. The byte arrays defined near labels PANEL36 and PANEL37 got turned
into junk, or more accurately into a sequence of Unicode replacement
characters.

<https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/SELECT/USA.INF>

This blunder is all the more regrettable because similar problems
affected the previous GW-BASIC source release (very old MASM versions
cannot deal with UNIX style line endings).

<https://www.os2museum.com/wp/gw-basic-source-notes/>

The timestamp destruction makes it harder to pin down what the source
code actually is. The DOS 4.0 release was very confused because IBM
first released PC DOS 4.0 in June 1988 (files dated 06/17/1988), but
soon followed with a quiet update (files dated 08/03/1988) where the
disks were labeled 4.01 but the software still reported itself as 4.00.

The just released source code almost certainly corresponds to this quiet
4.01 update. At least one source comment implies 8/5/88 modification,
i.e. August 1988.

At least the core files (IO.SYS, MSDOS.SYS, COMMAND.COM, FORMAT.COM,
FDISK.SYS, SYS.COM) built from the source release are a perfect match
for the files on "MS-DOS 4.00" disk images that can be found on
winworldpc.

<https://winworldpc.com/product/ms-dos/4x>

Said files are dated 10/06/1988 and DOS reports itself as 4.00. However,
the released source code, in the file SETENV.BAT, includes the following
line:

echo setting up system to build the MS-DOS 4.01 SOURCE BAK...

This further suggests that the source code in fact corresponds to the
quiet update of DOS 4.01 and not to the original IBM DOS 4.00 from June
1988, which to the best of my knowledge was never available from
Microsoft. After a few months, perhaps in late 1988 Microsoft changed
DOS to report itself as 4.01 because—unsurprisingly—the 4.00 version
number was confusing customers.

As a historic footnote, BAK stood for Binary Adaptation Kit. MS-DOS OEMs
would receive the BAK to adapt to their hardware. However, most OEMs did
not receive the full source code, only the code to components that
likely needed modification, such as IO.SYS.

But the fact that the "Source BAK" was something that Microsoft shipped
to (select lucky) customers is actually great—since it's supposed to be
built by 3rd parties, it includes all of the required tools and is in
fact quite easy to build.

Executive Summary
=================
It's terrific that the source code for DOS 4.00/4.01 was released! But
don't expect to build the source code mutilated by git without problems.

Historic source code should be released simply as an archive of files,
ZIP or tar or 7z or whatever, with all timestamps preserved and every
single byte kept the way it was. Git is simply not a suitable tool for
this.

From:
<https://www.os2museum.com/wp/how-not-to-release-historic-source-code/>

Comments
========
According to HN comments, some of the source was even censored a bit as
a hot-fix (original contained a not-so-nice comment about Tim Paterson):

<https://news.ycombinator.com/item?id=40163766>

On Fri, 26 Apr 2024 21:21:52 -0000 (UTC), Ben Collver wrote:

> But please please don't mutilate historic source code by shoving it into
> (stupid) git.

Well, Linus himself described Git as “the stupid content tracker”. It’s
even in the man page synopsis.

> First of all, git does not preserve timestamps, which causes
> irreversible damage. Knowing when a source file was last modified is
> valuable information.

One that can be recorded in Git, the same way you would in any other VCS:
use the commit date. You want help to figure that out? Have a look at the
fake_git script here <https://bitbucket.org/ldo17/fake_vcs/src/master/>.

> Well, this is what could go wrong:

Wonderful. Posting screen shots of text error messages, instead of posting
the actual text itself. Has this become some kind of ingrained habit among
DOS/Windows users? Is software development still some kind of novelty to
you?

On Fri, 26 Apr 2024, Ivan Shmakov wrote:

>>>>>> On 2024-04-25, Ben Collver wrote:
>
> > It looks as though some effort was put into composing this
> > message. Nice work, assuming it is human generated.
>
> When working time and again as a part-time university
> lecturer, I'd typically feed bits of my students' works to
> Duckduckgo to detect plagiarism. Makes me wonder if this
> approach can be adapted for detecting AI-generated texts.

Granted, it is not university level work or students, but what I do is to
just compare students work. The AI-people more often than not, hand in the
exact same source, same spelling, same variable names. That is enough
proof for me to not pass them.

But sophisticated cheaters rewrite, and then it is of course a bit more
difficult. In that case I do manage to catch them during code reviews when
they cannot explain what they do or the algorithm.