DOS ain't dead

> > > Of course tastes may differ and I remember that porting FreeDOS to
> other
> > > processors has already been a topic many years ago, so you can expect
> > that
> > > your target audience does exist, but I myself do not expect it to be
> > large.
>
> Good point - yes - for what reason do people want
> to port FreeDOS to other architectures? Maybe they
> are just wasting time though - they're not really
> planning on using the end result.

The Lenovo Yoga I linked above brags "always on, always connected", lightweight 2.6 lbs, up to 22 hours battery life. So just for battery life alone ARM is attractive.

> > DOS/NT (predecessor to DOS-C) ran atop 68k processors for a client,
> right?
> > But it was very limited. Full MS-DOS portability is harder for other
> > architectures (needing some emulation).
>
> Could you please expand on this? What is "Full
> MS-DOS portability" and why is it hard?

I'm basically paraphrasing this:

> This version of the kernel is intended only for 8086+ or 80386+
> IBM compatible computers in continuation of the goals of the FreeDOS
> Project. Please see http://www.fdos.org/kernel for my 0xDC kernel
> that is work on merging back in some of the original portability aspects
> and other supported features at the cost of some compatibility with older
> hardware/software.

> Good point - yes - for what reason do people want
> to port FreeDOS to other architectures?

That's easy. Nobody wants to port FreeDos to any other architecture.

> Maybe they
> are just wasting time though - they're not really
> planning on using the end result.
Yes indeed.

> > > I remember that porting FreeDOS to other
> > > processors has already been a topic many years ago [...]
>
> > DOS/NT (predecessor to DOS-C) ran atop 68k processors for a client,
> right?
> > But it was very limited. Full MS-DOS portability is harder for other
> > architectures (needing some emulation).
>
> Could you please expand on this? What is "Full
> MS-DOS portability" and why is it hard?

The summary of the 68k portability case can be found in

https://en.wikipedia.org/wiki/Pat_Villani#FreeDOS_involvement

Pat Villani had written XDOS which grew to NSS-DOS and DOS/NT:

"When one potential contractor sought to use the OS in a system equipped with Motorola 680x0 processors instead of Intel x86 processors, for which the system was designed originally and which utilize different instruction sets and memory models, Villani was able to redesign his system to become portable across a range of different compilers and target environments"

In the DOS-C reincarnation, that kernel became the basis of the FreeDOS kernel 30 years ago. There have been many changes since then and Pat Villani died in 2011, so he had to miss the latest developments for more than a decade now.

---
FreeDOS / DOSEMU2 / ...

> > > > I remember that porting FreeDOS to other
> > > > processors has already been a topic many years ago [...]
> >
> > > DOS/NT (predecessor to DOS-C) ran atop 68k processors for a client,
> > right?
> > > But it was very limited. Full MS-DOS portability is harder for other
> > > architectures (needing some emulation).
> >
> > Could you please expand on this? What is "Full
> > MS-DOS portability" and why is it hard?
>
> The summary of the 68k portability case can be found in
>
> https://en.wikipedia.org/wiki/Pat_Villani#FreeDOS_involvement
>
> Pat Villani had written XDOS which grew to NSS-DOS and DOS/NT:
>
> "When one potential contractor sought to use the OS in a system equipped
> with Motorola 680x0 processors instead of Intel x86 processors, for which
> the system was designed originally and which utilize different instruction
> sets and memory models, Villani was able to redesign his system to become
> portable across a range of different compilers and target environments"

That article continues:

"This move to a completely different target platform, while losing binary compatibility with existing applications, would have required a complete rewrite from scratch had his system not been written in a high-level language such as C, which allowed him to reuse large parts."


Which is exactly my experience. ie writing in C makes porting the OS relatively easy. At least the core functionality that an OS needs to provide (managing the filesystem, managing memory, providing APIs).

The core of MSDOS is actually the same as Unix with open/read/write/seek/close - and the source code of MSDOS even mentions Xenix.

I assume that due to limited memory, tools and processor speed, MSDOS was hand-coded in assembler rather than simply copying the Xenix code (had it been written in C). Which is fine for the 8086. But if you need to port to some other environment then the MSDOS basics - if written in C - ie Xenix-like - should be portable.

So it depends what is meant by "full MSDOS portability". The fact that it is being ported clearly speaks to the fact that the application API is not going to be accepting segment/offset pairs in 8086 registers. It is clear that the interface is going to accept some sort of appropriate pointer for the system (ie same as Unix/Windows and presumably Xenix).

And so once you establish an "appropriate API" (which cannot possibly be 8086 registers on a 68000), then I'm not sure what the terms "limited", "full MSDOS portability" and "hard" even mean.

I mean - yes it's hard to write an OS (although some people dispute that). But that's the case even if you're not trying to achieve MSDOS compatibility. And again - all OSes essentially support C90 - so they're all essentially MSDOS compatible anyway.

Sorry if I rambled somewhat, but this is my exact interest for 30 years.

> The core of MSDOS is actually the same as Unix with
> open/read/write/seek/close

with the absolute minor difference that Unix is multitasking, and MSODS is definitively not.

> > The core of MSDOS is actually the same as Unix with
> > open/read/write/seek/close
>
> with the absolute minor difference that Unix is multitasking, and MSODS is
> definitively not.

The discussion under question is porting MSDOS
and/or applications, not porting Unix.

So MSDOS support can be provided to the Unix
system by *doing nothing at all*.

Unless you want to define terms (which is my
exact interest).

BFN. Paul.

Hello kerravon,

> > with the absolute minor difference that Unix is multitasking, and MSODS
> > is
> > definitively not.
> The discussion under question is porting MSDOS
> and/or applications, not porting Unix.
> So MSDOS support can be provided to the Unix
> system by *doing nothing at all*.

Indeed, indeed... the problem of getting MS-DOS programs to run on a multi-tasking system is so trivial, that Raymond Chen wrote an entire book chapter about it (https://news.ycombinator.com/item?id=9070696).

Thank you!

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

> Hello kerravon,
>
> > > with the absolute minor difference that Unix is multitasking, and
> MSODS
> > > is
> > > definitively not.
> > The discussion under question is porting MSDOS
> > and/or applications, not porting Unix.
> > So MSDOS support can be provided to the Unix
> > system by *doing nothing at all*.
>
> Indeed, indeed... the problem of getting MS-DOS programs to run on a
> multi-tasking system is so trivial, that Raymond Chen wrote an entire book
> chapter about it
> (https://news.ycombinator.com/item?id=9070696).

Well - now we're onto a different topic of great
interest to me - why?

If they were written in 8086 assembler then of
course they're not expected to port to a Linux 68000
machine.

I'm talking about source code portability here.

Do you agree that if the MSDOS programs were
written conforming to C90 that they would port?

Then the question is - why weren't they written
in C90?

And the answer to that question would then open
up the possibility of finding out if there was
a way to overcome that (presumed) issue without
breaking portability.

But it starts with programs that work on MSDOS.
Not programs that work on Linux. The goal is
to get the MSDOS programs across - with a
recompile. And if that is not possible - why not?

BFN. Paul.

> But it starts with programs that work on MSDOS.
> Not programs that work on Linux. The goal is
> to get the MSDOS programs across - with a
> recompile. And if that is not possible - why not?

Note that straying outside of C90 brings a requirement
of making directories under MSDOS. Which is tied to a
FAT filesystem with particular characteristics.

When moving to Linux ARM or any other machine, I fully
expect a FAT file system to exist if the MSDOS program
is to behave correctly.

So is there a problem making the API to make a directory
consistent for (any high level language) so that it can
be ported to (ARM-anything with FAT)?

Wasn't the API already fairly consistent, set by
Microsoft C and their dos.h or io.h (which I never
used - so I'm asking now if they are appropriate,
and if not, why not)?

BFN. Paul.

Hello kerravon,

> > > So MSDOS support can be provided to the Unix
> > > system by *doing nothing at all*.

> I'm talking about source code portability here.
> Do you agree that if the MSDOS programs were
> written conforming to C90 that they would port?

Some of the examples cited by Mr. Chen are written very much in C. Unfortunately they still do not work properly on a multi-tasking system (for reasons that will be obvious).

Anyway, you are basically saying that programs that are easy to port are ... easy to port. Such a statement is (by definition) 100% true, but also 100% useless for practical purposes.

> Then the question is - why weren't they written
> in C90?
> And the answer to that question would then open
> up the possibility of finding out if there was
> a way to overcome that (presumed) issue without
> breaking portability.

That sounds like somewhat more effort than "doing nothing at all". Unless you also wish to argue over the definition of "nothing".

In practical terms, when it comes to thinking about how to bring MS-DOS programs into a multi-tasking world, someone like Raymond Chen, who at the very least has been there "in the trenches", has more cachet to me. He knows whereof he speaks.

Do you think you happen to know something he does not? And why?

Thank you!

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

> Anyway, you are basically saying that programs that are easy to port are
> ... easy to port. Such a statement is (by definition) 100% true, but also
> 100% useless for practical purposes.

Depends what you call "practical purposes".

I am basically trying to set programming
standards for myself to follow even if noone
else does.

> > Then the question is - why weren't they written
> > in C90?
> > And the answer to that question would then open
> > up the possibility of finding out if there was
> > a way to overcome that (presumed) issue without
> > breaking portability.
>
> That sounds like somewhat more effort than "doing nothing at all". Unless
> you also wish to argue over the definition of "nothing".

The initial body of work - writing software -
obviously needs to be done, and obviously
isn't nothing.

And creating the standards wasn't "nothing"
either.

But perhaps it is the ANSI X3J11 committee I think
it was called that fell short.

They probably fell short for quite valid reasons.

One of them being that they needed to produce
something ASAP, not wait 35 years like I have done.

So I don't think they would have got everything
right when it comes to setting standards for
MSDOS programmers to follow, that will, 35 years
later, allow those programs to port to that ARM
computer with a battery life of 22 hours.

> In practical terms, when it comes to thinking about how to bring MS-DOS
> programs into a multi-tasking world, someone like Raymond Chen, who at the
> very least has been there "in the trenches", has more cachet to me. He
> knows whereof he speaks.
>
> Do you think you happen to know something he does not? And why?

I've spent 35 years writing C90-compliant software
and it ports just fine to anywhere.

Even to the mainframe. And I even made the mainframe
conform to an EBCDIC version of ANSI X3.64 so that I
could have fullscreen apps.

You could argue that ANSI X3.64 is insufficient in
the MSDOS world - you need more colors than ANSI
defines to be commercially successful or something
like that.

And once you move to graphics all bets are off as
I haven't gone there yet.

If that's the answer - so be it.

But I'd like to first establish that when it comes
to text - even fullscreen text (which is the limit
of what blind people can "read"), there is no reason
why an MSDOS application can't be written in a
language other than assembler and be portable to
basically anywhere.

Can you cite a system call or concept or technique
that an MSDOS programmer must use (presumably to
either fit in 640k or to be commercially viable)
and by doing so, the program cannot port?

If the answer is "direct writes to 0xb8000 cannot
be avoided" then I would like to ask followup
questions.

BFN. Paul.

Hello kerravon,

> > Do you think you happen to know something he [Raymond Chen] does not [about porting MS-DOS code to multi-tasking platforms]? And why?
> I've spent 35 years writing C90-compliant software
> and it ports just fine to anywhere.

So I suppose the answer is "no" then. Thank you, and good day.

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

> Hello kerravon,
>
> > > Do you think you happen to know something he [Raymond Chen] does not
> [about porting MS-DOS code to multi-tasking platforms]? And why?
> > I've spent 35 years writing C90-compliant software
> > and it ports just fine to anywhere.
>
> So I suppose the answer is "no" then. Thank you, and good day.

I suppose you still can't quote a single essential
MSDOS syscall or concept that can't possibly be ported
beyond MSDOS?

I haven't found one in 35 years either, so I'm not
surprised.

Names of people don't impress me. An INT 21H call
that I could look up and that can't possibly be
avoided would impress me.

I doubt that it exists, but if you give me the
number, I'll look up RBIL and see this amazing
concept that only exists in MSDOS.

BFN. Paul.

Hello kerravon,

Erm, you are the one proposing your project. So actually the onus is on you to convince us that your project is viable and can actually offer something of value to the world. We are the ones who get to ask questions about your project.

Thank you!

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

> Erm, you are the one proposing your project. So actually the onus is on
> you to convince us that your project is viable and can actually
> offer something of value to the world. We are the ones who get to ask
> questions about your project.

That's a different question.

My question about whether MSDOS programs can be
written portably or not remains.

As to the other question of my project being viable -
I'm not sure I actually stated it was or that I
even understand the concept. Can you quote what I
said? Viable for what purpose?

Have you seen the warnings software generally comes
with? This product is not warranted to be suitable
for any particular purpose etc etc? You can add
anything I produce to that list.

I do have a C compiler and toolchain on 32-bit ARM
though. I'm not warranting it, but you should be
able to write anything you want (in C90) using
that, if there is something you wish to achieve.
Or port other C90-compliant software that achieves
some purpose you desire.

Which is somewhat amusing because that's largely
where I stop. ie I stop at the point where a C90
compiler is available so that you can theoretically
do whatever you want with sufficient effort and
without resorting to assembler coding. With more
memory than is available on MSDOS. Doing the
reverse may not be possible for that exact reason.

And you can apparently do it for 22 hours on a
single battery charge. At which point - get
some sleep!

BFN. Paul.

Another new version:

https://github.com/o-ksi-d/Pdos-PdAndro/releases/tag/rel.0.0.58

Ad new ucarm.zip from http://pdos.org

> On my Pinebook Pro using ucarm.zip (bios.exe), I was
> required to put in a 0.02 second delay before
> executing any executable code (just placed into
> memory (BSS)). Otherwise it would sometimes work,
> sometimes crash. It's like either Linux or the
> ARM chips is caching something and the cache
> needs to be cleared.
>
> I have an ARM v7 netbook and 0.02 seconds wasn't
> enough. I added a full 1 second and have had no
> problem since.

These delays have now been removed.

While investigating a hard fault on macOS when
trying to do mprotect(), I eventually stumbled
onto

https://chromium.googlesource.com/chromiumos/docs/+/master/constants/syscalls.md

983042 ARM_cacheflush

which worked perfectly (my heart was in my mouth as
I waited to see if that worked - and I nearly
misdiagnosed that it didn't work).

So anyway - this is a fantastic DOS-like machine now
that the major technical hurdle has been overcome.

BFN. Paul.

> Not sure if that one uses Secure Boot (and presumably you aren't interested
> in modern Mac laptops which also use ARM64). Windows ARM64 and Snapdragon
> are still sold, but newer Lenovo Yogas seem to only use x64.

It took a while for this to sink in.

There is a Windows 11 for ARM64.

Do you know if there is the equivalent of msvcrt.dll for it?

And the equivalent of mingw64.

I ran into a fundamental problem with the Mac - it
doesn't allow rwx memory, which PDOS-generic depends on.

Apparently you have to run a virtual machine if you want
that, so that the Silicon stuff is disabled, but you still
get near-native speed.

And you can create a virtual machine via free Xcode download.

And then you can run Linux.

Which would then allow me to run a pseudo-bios built as
a Linux ELF executable.

Then I would be in a position to run PDOS-generic apps.
But I still need to choose an executable format for
those. I could go with ELF, but if Windows has created
PE then I'd rather go with that, which is better
supported by exeload.c in PDOS. And that would also
be the format I would use for directly running on a
UEFI ARM64 machine.

So assuming I go in that direction, it is a Windows
ARM64 laptop I need to buy, not a Macbook. Note that
I tested PDPCLIB on an iMac and later I discovered
that they had taken away rwx memory. If you make
your program more complicated you can make it work,
but I'd rather keep it simple. I'm running pdos-generic
anyway. It doesn't matter if it is inside Linux inside
macOS rather than directly under either. They are all
being treated as glorified BIOSes.

BFN. Paul.

> I know nothing about ARM programming etc. but I would be interested in
> running programs that I want to write myself for an android smartphone.
> Would your work allow say a FreeBASIC program to be launched from a
> smartphone?

As I mentioned before - if FreeBASIC is C90-compliant,
it should be able to be built for PdAndro.

However, I'm only familiar with bwbasic - which is an
interpreter. So yesterday I built that and that is now
available if you get the latest PdAndro from here:

https://github.com/o-ksi-d/Pdos-PdAndro/releases/tag/rel.0.61.0

and UCARM from http://pdos.org

You just need to type "bwbasic" and then you can go:
print 3 + 4

Or you can use the included microemacs and go:

e test.bas

then:

for x = 1 to 5
print "hi", x
next

ctrl-x, ctrl-s to save
ctrl-x, ctrl-c to exit
(ctrl-g to cancel if you stuff up a command)

Then

bwbasic test.bas

There is a BASIC tutorial available at http://pdos.org
which I intend to update soon for this new environment
and include in ucarm.zip

The One Laptop Per Child people never managed to get
the price below US$200.

Smartphones are ubiquitous worldwide. For US$2 you can
turn it into a computer and start learning how to
program.

When you've cut your teeth on BASIC, you can move to the
included C compiler.

There is only one small fly in the ointment. I had to
make a special version of bwbasic that doesn't use floating
point, as floating point is not yet properly supported in
this environment. For some reason the ARM hardware doesn't
have the instructions, and there is no software emulation
being done somewhere that would cover it. I could use
soft-float but don't have floating point routines of my
own (pdpclib just has stubs which are enough for some
things but not if you really want to use floating point).

BFN. Paul.

> Well, PDOS-generic, anyway.
>
> Commands date/time, copy, dir, type, exit are working.
>
> Works on ARM Chromebook, Android smartphone and Android netbook.

After a lot of work, PdAndro was updated to support ARM64,
which meant it was potentially able to go on the Google Play Store.

It has just been accepted:

https://play.google.com/store/apps/details?id=com.cod5.pdos_pdandro&hl=en&gl=US

And as of a few hours ago, the last bug that was affecting
me in pdld was fixed, so I am building a new PDOS distribution.

PdAndro and PDOS-generic go hand-in-hand.

And what that means is that you will have a properly working
bwbasic and microemacs available.

The current release does have bwbasic, but it is integer-only
and interactive-only.

It takes me about half a day to cut a release.

So after all that effort - you basically get MSDOS and
gwbasic back. They can take away my DOS prompt when they
pry it from my cold, dead hands.

BFN. Paul.

> Not sure if that one uses Secure Boot (and presumably you aren't interested
> in modern Mac laptops which also use ARM64). Windows ARM64 and Snapdragon
> are still sold, but newer Lenovo Yogas seem to only use x64.

So - here's the direction I went.

I wasn't able to buy a new Windows ARM laptop in the Philippines.
Or even purchase one from Amazon and get it shipped. But I did
manage to find one - an older model I think - from ebay, which
shipped here.

And so it turns out that Windows 11 for ARM supports both 32-bit
ARM and 64-bit ARM, and just like x86/x64 has an msvcrt.dll for
both environments.

Not only that, but Visual Studio is able to target both ARM32
and ARM64 from any environment. The command prompt for ARM32
doesn't come up automatically though, so you have to copy an
existing shortcut. But all the material is included.

In both cases I was able to replace the Visual Studio C library
with PDPCLIB and stand up Win32 ARM32 and Win64 ARM64 mini-clones
that operate under UEFI, Linux or Android (via PdAndro).

And for ARM32 I was eventually able to modify my fork of gcc 3.2.3
to produce Win32 ARM32 compatible code, so I have an entire
toolchain for ARM32 (but not ARM64 which relies on Visual
Studio still).

For good measure I bought Visual Studio Professional.

So from my Zhaoxin Windows 10 I am able to build a Win64 ARM64
mini-clone.

I bought a Macbook M1 and Oracle Virtualbox can run on that,
and gives me an ARM64 UEFI environment, so that I can run my
Windows mini-clone.

I then fleshed out my mainframe (S/370, z/Arch) emulator so
that it was capable of running z/PDOS-generic.

So that is basically the one application that I run under
my Win64 ARM64 mini-clone.

The thing about mainframes is that they are too expensive
to buy, that you basically have to run under emulation anyway.

z/PDOS-generic is still being debugged, but it is expected to
provide a full toolchain. There has been a lot of work recently
by the creator of Linux Bigfoot to get binutils to support
mainframe hlasm.

So - this setup gives a mainframe on an ARM64 Macbook.

This is a physically more reliable machine than my Pinebook Pro.

And if I power my Macbook down, I can charge it using a cheap
powerbank.

And I can charge my cheap powerbank using a portable solar.

So. I have a mainframe that is (or can be) powered by the Sun.

And I am expected to have a complete toolchain that allows me
to reconstruct anything I want in pure C90.

And for those operating on a budget, you can do the same thing
using a smartphone or tablet with an external keyboard.

A mainframe emulator seems to be a lot less complicated than
an x86 emulator.

My mainframe emulator is only suitable for running z/PDOS-generic,
because it replaces the pseudo-bios too.

I'm still waiting for the bugs to be fixed so that I can see
how long it takes my Mac M1 to get gcc 3.2.3 to rebuild itself
at full optimization under an emulator. Normally it takes me
a couple of hours under Hercules on an x86. But now I am
switching emulator and processor.

I don't have the ability to use clang to replace Visual Studio
as the compiler to produce my Win64 ARM64 software, as I don't
seem to have the ability to switch off "pie".

But given time, I should be able to stand up a replacement
ARM64 compiler, using my mini mainframe.

Note that I consider z/PDOS-generic to be what MSDOS would
be if it had been ported to the mainframe. Or similar, anyway.

Regardless, I am basically happy that I have found alternative
hardware - but still in laptop form - so I am not beholden to
the x86 processor - but also I am not beholden to the Apple
software infrastructure. It's merely a means to an end.

BFN. Paul.

[SNIP]
> I'm still waiting for the bugs to be fixed so that I can see
> how long it takes my Mac M1 to get gcc 3.2.3 to rebuild itself
> at full optimization under an emulator. Normally it takes me
> a couple of hours under Hercules on an x86. But now I am
> switching emulator and processor.
[SNIP]

Building gcc should not take hours on any relatively modern hardware. build-djgpp takes 33 minutes on an 8 year old CPU. And build-djgpp builds more than just gcc. It also builds binutils, a BSD libc and some other supporting libs. On 10 year old server hardware, you can build gcc, binutils, busybox, and the Linux kernel in about 15 minutes.

Do you have access to a multi-core machine? Are you enabling the -j parameter in make when possible? Have you considered using https://github.com/richfelker/musl-cross-make?

> [SNIP]
> > I'm still waiting for the bugs to be fixed so that I can see
> > how long it takes my Mac M1 to get gcc 3.2.3 to rebuild itself
> > at full optimization under an emulator. Normally it takes me
> > a couple of hours under Hercules on an x86. But now I am
> > switching emulator and processor.
> [SNIP]
>
> Building gcc should not take hours on any relatively modern hardware.
> build-djgpp takes
> 33
> minutes on an 8 year old CPU. And build-djgpp builds more than just
> gcc. It also builds binutils, a BSD libc and some other supporting libs.
> On 10 year old server hardware, you can build gcc, binutils, busybox, and
> the Linux kernel
> in
> about 15 minutes.

I said I was running under the Hercules emulator.
Which is something like 60 times slower than
running native.

> Do you have access to a multi-core machine? Are you enabling the
> -j parameter in make when possible? Have you
> considered using
> https://github.com/richfelker/musl-cross-make?

I compile on MVS/380, using JCL, not make.

BFN. Paul.