DOS ain't dead

Well, PDOS-generic, anyway.

Commands date/time, copy, dir, type, exit are working.

Works on ARM Chromebook, Android smartphone and Android netbook.

https://github.com/jeanmarclienher/Pdos-PdAndro/releases/tag/rel0.7.0

> Well, PDOS-generic, anyway.
>
> Commands date/time, copy, dir, type, exit are working.
>
> Works on ARM Chromebook, Android smartphone and Android netbook.
>
> https://github.com/jeanmarclienher/Pdos-PdAndro/releases/tag/rel0.7.0

Hi Paul. An ARM version of MS-DOS is no MS-DOS. I may look and behave similar to MS-DOS, but it cannot run real (x86) DOS software. So it's not "MSDOS".

---
Forum admin

> > Well, PDOS-generic, anyway.
> >
> > Commands date/time, copy, dir, type, exit are working.
> >
> > Works on ARM Chromebook, Android smartphone and Android netbook.
> >
> > https://github.com/jeanmarclienher/Pdos-PdAndro/releases/tag/rel0.7.0
>
> Hi Paul. An ARM version of MS-DOS is no MS-DOS. I may look and behave
> similar to MS-DOS, but it cannot run real (x86) DOS software. So it's not
> "MSDOS".

It runs "real" DOS software at the source code
level if the Pos interface is used.

Some people were looking forward to a 32-bit
version of MSDOS.

If Microsoft had produced a 32-bit version of
MSDOS that ran in PM32 and required people to
recompile using a 32-bit compiler, and didn't
run 16-bit software, would you have said

"Microsoft's 32-bit MSDOS may look and behave
similar to MSDOS, but it cannot run real (8086)
DOS software, so it's not MSDOS"?

And if Microsoft had produced a version of
MSDOS for the Atari (68000), would you have said
that that wasn't "real" either?

Would you have said that CP/M-86 (a real thing)
is not "real CP/M" because it doesn't run CP/M
8080 binaries?

Hello kerravon, hello rr,

> Would you have said that CP/M-86 (a real thing)
> is not "real CP/M" because it doesn't run CP/M
> 8080 binaries?

OK, let us put the philosophical questions aside.

Can this PDOS/ARMv7 run Doom now?

Or, can it at least run donkey.bas?

Thank you!

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

> Hello kerravon, hello rr,
>
> > Would you have said that CP/M-86 (a real thing)
> > is not "real CP/M" because it doesn't run CP/M
> > 8080 binaries?
>
> OK, let us put the philosophical questions aside.

Actually, a better example would have been is
Linux running on a z/Arch mainframe not "real
Linux" because it doesn't run 80386 binaries?

And I believe Windows has an ARM port - is that
not real Windows?

And the original Windows was 16-bit anyway - I
don't think Windows 11 runs 16-bit software
at all. It will be news to Microsoft if Windows
11 is not "real Windows".

The philosophical question is interesting.

> Can this PDOS/ARMv7 run Doom now?
>
> Or, can it at least run donkey.bas?

No, it's not that sophisticated yet.

I listed the supported commands already.

This is pdos-generic, not pdos/386 or even pdos/86.

Note that PDOS/386 recently returned to no-VM so
the distribution currently available allows
unrestricted access to SVGA graphics as seen by
the supplied "graphtst" program. ie in PM32.

BFN. Paul.

Hello kerravon,

> The philosophical question is interesting.

Even if it is "interesting", it is not very useful.

If your PDOS/whatever is to have any chance of "competing" against Microsoft Windows — or achieving whatever other grandiose goals you have for it — then it probably needs to be able to run Doom. Or donkey.bas. Or preferably both.

And, I mean, a lot of OSes that don't even claim to be spiritual successors of MS-DOS can already run Doom. Surely a self-styled "ARM version of MSDOS" can at least strive to do better in this department.

Thank you!

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

> Hello kerravon,
>
> > The philosophical question is interesting.
>
> Even if it is "interesting", it is not very useful.

It's very useful in setting goals. And setting a
definition for that goal.

> If your PDOS/whatever is to have any chance of "competing" against
> Microsoft Windows — or achieving whatever other grandiose goals you have
> for it — then it probably needs to be able to run Doom. Or donkey.bas.
> Or preferably both.

I don't know what donkey.bas is, but PDOS/386 comes
with bwbasic, which is a BASIC interpreter.

> And, I mean, a lot of OSes that don't even claim to be spiritual
> successors of MS-DOS can already run Doom. Surely a self-styled "ARM
> version of MSDOS" can at least strive to do better in this department.

Honestly, I have been using Android smartphones for
about a year, and seeing an MSDOS prompt (or similar)
come up and being able to do a "dir", which only
happened a few hours ago, is fantastic already, and
the culmination of decades of effort.

BFN. Paul.

Hello kerravon,

> I don't know what donkey.bas is, but PDOS/386 comes
> with bwbasic, which is a BASIC interpreter.

Consider this as a challenge: Find out what donkey.bas is. Then get PDOS/386 or PDOS/whatever to run it. Then we are talking. You will not regret it.

Thank you!

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

> Well, PDOS-generic, anyway.
>
> Commands date/time, copy, dir, type, exit are working.
>
> Works on ARM Chromebook, Android smartphone and Android netbook.
>
> https://github.com/jeanmarclienher/Pdos-PdAndro/releases/tag/rel0.7.0

calling an OS MSDOS because it supports date/time, copy, dir, type, exit
is even a bit more demanding than Jim Halls's "more than a dozen utilities"

asking to run gorilla.bas (which requires a genuine MS interpreter) or DOOM (which I agree is pretty demanding), is indeed a high margin to clear.

I suggest coming back when you can run Norton Commander or any of its clones; no matter if on ARM or X86.

> Well, PDOS-generic, anyway.
>
> Commands date/time, copy, dir, type, exit are working.
>
> Works on ARM Chromebook, Android smartphone and Android netbook.
>
> https://github.com/jeanmarclienher/Pdos-PdAndro/releases/tag/rel0.7.0

I'll allow referring to this as a DOS. After all there were many Disk Operating Systems out there, not all 8086-based MS-DOS-compatibles.

However, what interests most of us here is the family of DOSes that I call 86-DOS. They are based on the original 8086, compatibles, or running applications in the Real or Virtual 86 Mode of more recent x86 machines. DPMI adds 16-bit and 32-bit PM capabilities, but the common thread is still an 86-DOS compatible interface.

---
l

> And I believe Windows has an ARM port - is that
> not real Windows?

(Disclaimer: I'm not disagreeing with you. This is not a criticism.)

I believe the ARM 64-bit (Qualcomm Snapdragon?) version of Windows has native drivers but userland IA-32 emulation up through Pentium 4 (SSE2) and DirectX 9 through 12. (The main appeal there is supposedly "always on" and long battery life.)

> > Well, PDOS-generic, anyway.
> >
> > Commands date/time, copy, dir, type, exit are working.
> >
> > Works on ARM Chromebook, Android smartphone and Android netbook.
> >
> > https://github.com/jeanmarclienher/Pdos-PdAndro/releases/tag/rel0.7.0
>
> I'll allow referring to this as a DOS. After all there were many Disk
> Operating Systems out there, not all 8086-based MS-DOS-compatibles.
>
> However, what interests most of us here is the family of DOSes that I call
> 86-DOS. They are based on the original 8086, compatibles, or running
> applications in the Real or Virtual 86 Mode of more recent x86 machines.
> DPMI adds 16-bit and 32-bit PM capabilities, but the common thread is still
> an 86-DOS compatible interface.

And if applications written for 86-DOS, at least
moving forward, use the Pos* interface, they can
be recompiled as 80386-DOS and ARMv7-DOS, with
no source code changes.

BFN. Paul.

> I suggest coming back when you can run Norton Commander or any of its
> clones; no matter if on ARM or X86.

I suggest we redesign MSDOS with a view to an
ARM v7 eventual port.

I've produced a POC but I am not claiming it is
perfect. I'm after feedback.

> Hello kerravon,
>
> > I don't know what donkey.bas is, but PDOS/386 comes
> > with bwbasic, which is a BASIC interpreter.
>
> Consider this as a challenge: Find out what donkey.bas is. Then get
> PDOS/386 or PDOS/whatever to run it. Then we are talking. You will
> not regret it.

I'm only interested in C90 plus MSDOS-like
extensions replacing Posix crap, not BASIC.

I have made an opening offer for an MSDOS-like
API to replace Posix, at least for small systems
like the 8086 that have no virtual memory so can't
do Unix nonsense like fork().

Hello kerravon,

> > Consider this as a challenge: Find out what donkey.bas is. Then get
> > PDOS/386 or PDOS/whatever to run it. Then we are talking. You
> will
> > not regret it.
> I'm only interested in C90 plus MSDOS-like
> extensions replacing Posix crap, not BASIC.

Duuude.

I have four words for you: Talk less. Do more.

Then maybe your OS will be able to do much more than copy files and delete files after a few more decades.

Thank you!

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

Hello tom,

> asking to run gorilla.bas (which requires a genuine MS interpreter) or DOOM
> (which I agree is pretty demanding), is indeed a high margin to clear.

donkey.bas, not gorilla.bas! I suspect donkey.bas might not be as hard to "port" to a ARMv7-based chip running non-Microsoft code, as it might first seem.

Google recently (2018) put out a JavaScript-based BASIC interpreter that can already run donkey.bas: https://github.com/google/wwwbasic .

The donkey.bas code contains one POKE into the BASIC interpreter's data segment — which is OK to ignore — and one PEEK into the IBM BIOS's data area.

> I suggest coming back when you can run Norton Commander or any of its
> clones; no matter if on ARM or X86.

I guess that will also be a good goal to aim for.

Thank you!

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

> I suggest coming back when you can run Norton Commander or any of its
> clones; no matter if on ARM or X86.
A "DOS-like" OS on the ARM does sound exciting and enchanting. I appreciate your work and effort toward that end. We all start somewhere, and with ARM processors becoming more and more used, probably soon to 'replace' Intel chips due to reduced instruction set and scalability, we'll be "forced" to abandon Intel artechicture soon. So, "MS-DOS for ARM" is most welcomed, indeed.

Get Xtree Gold running on the ARM, and I'll be impressed! This is the "best" file manager / viewer / utility for DOS ever made, in my opinion. I still use it daily, and its interface is perfect.

> > asking to run gorilla.bas (which requires a genuine MS interpreter) or
> DOOM
> > (which I agree is pretty demanding), is indeed a high margin to clear.
>
> donkey.bas, not gorilla.bas! I suspect donkey.bas might not be as hard to
> "port" to a ARMv7-based chip running non-Microsoft code, as it might first
> seem.

I think for modern platforms, QB64 is probably one of the better options (outputting to C++ with libraries).

> A "DOS-like" OS on the ARM does sound exciting and enchanting. I appreciate
> your work and effort toward that end. We all start somewhere, and with ARM
> processors becoming more and more used, probably soon to 'replace' Intel
> chips due to reduced instruction set and scalability, we'll be "forced" to
> abandon Intel artechicture soon. So, "MS-DOS for ARM" is most welcomed,
> indeed.

Just for comparison:

> FreeBSD 13.1-RELEASE is now available for the amd64, i386,
> powerpc, powerpc64, powerpc64le, powerpcspe,
> armv6, armv7, aarch64,
> and riscv64 architectures.

So it's not all Intel/AMD or ARM.

> Get Xtree Gold running on the ARM, and I'll be impressed! This is the
> "best" file manager / viewer / utility for DOS ever made, in my opinion. I
> still use it daily, and its interface is perfect.

There are several clones, e.g. Ytree.

> > I suggest coming back when you can run Norton Commander or any of its
> > clones; no matter if on ARM or X86.
>
> I suggest we redesign MSDOS with a view to an
> ARM v7 eventual port.
>
> I've produced a POC but I am not claiming it is
> perfect. I'm after feedback.

POC? Oh, proof of concept?

If you read the Wikipedia page of Pat Villani, you'll see that he had several kernels before DOS-C that even ran on Motorola 68k machines (for one contractor). So it is possible, but it won't be 100% binary compatibility without some partial emulation.

> There are several
> clones, e.g.
> Ytree.
Thanks, I had never heard of Ytree, looks like a fabulous clone for Linux, just what I wanted and can use!

I've used Ztree for Windows for two decades as well, it's a great clone for NTFS, ExFAT, and has great LFN-native support, of course.

I believe Executive systems (original Xtree for DOS company) also made an Xtree for UNIX, if I remember. It was rare, and I never used it, but it exists.

> > > asking to run gorilla.bas (which requires a genuine MS interpreter) or
> > DOOM
> > > (which I agree is pretty demanding), is indeed a high margin to clear.
> >
> > donkey.bas, not gorilla.bas! I suspect donkey.bas might not be as hard
> to
> > "port" to a ARMv7-based chip running non-Microsoft code, as it might
> first
> > seem.
>
> I think for modern platforms,
> QB64 is probably one of the
> better options (outputting to C++ with libraries).



As far as I know, QB64 only runs on Intel 32/64 bit on Windows (Various versions), Linux, and MAC (Intel only) OS's.

FreeBASIC (competitor to QB64) - can run on DOS (special version of FreeBASIC - I have used FreeBASIC DOS version with FreeDOS), as well as Windows and LINUX. Do not know if can run on ARM processors.

> Hello kerravon,
>
> > > Consider this as a challenge: Find out what donkey.bas is. Then get
> > > PDOS/386 or PDOS/whatever to run it. Then we are talking. You
> > will
> > > not regret it.
> > I'm only interested in C90 plus MSDOS-like
> > extensions replacing Posix crap, not BASIC.
>
> Duuude.
>
> I have four words for you: Talk less. Do more.
>
> Then maybe your OS will be able to do much more than copy files and delete
> files after a few more decades.

The OS I have spent the most work on - PDOS/386 - does
a lot more than just copy and delete files. It is
self-hosting, running a Windows GCC executable to do
that. I spent a few months with no access to Windows
or Linux (except for my Android phone), just using PDOS/386
and Freedos for development (on real hardware). I've almost
eliminated the need for Freedos.

Regardless, I'm already operating at my limit.

I don't do much else besides working on my OSes, from
the time I wake up. 7 days a week.

If you're far more productive than me, so be it. I haven't
seen any of your OSes.

BFN. Paul.

> > > I suggest coming back when you can run Norton Commander or any of its
> > > clones; no matter if on ARM or X86.
> >
> > I suggest we redesign MSDOS with a view to an
> > ARM v7 eventual port.
> >
> > I've produced a POC but I am not claiming it is
> > perfect. I'm after feedback.
>
> POC? Oh, proof of concept?
>
> If you read the Wikipedia page of
> Pat Villani, you'll
> see that he had several kernels before DOS-C that even ran on Motorola 68k
> machines (for one contractor). So it is possible, but it won't be 100%
> binary compatibility without some partial emulation.

I'm not even after 1% binary compatibility. I'm after
source code compatibility, and even willing to compromise
on that depending on what the question is.

BFN. Paul.

> > I suggest coming back when you can run Norton Commander or any of its
> > clones; no matter if on ARM or X86.
> A "DOS-like" OS on the ARM does sound exciting and enchanting. I appreciate
> your work and effort toward that end. We all start somewhere, and with ARM
> processors becoming more and more used, probably soon to 'replace' Intel
> chips due to reduced instruction set and scalability, we'll be "forced" to
> abandon Intel artechicture soon. So, "MS-DOS for ARM" is most welcomed,
> indeed.
>
> Get Xtree Gold running on the ARM, and I'll be impressed! This is the
> "best" file manager / viewer / utility for DOS ever made, in my opinion. I
> still use it daily, and its interface is perfect.

Someone else will have to port applications, especially
copyrighted applications.

My interest is limited to the OS and tools required to regenerate
the OS and the tools.

BFN. Paul.

Hello Rugxulo, hello Richard,

> > I think for modern platforms,
> > QB64 is probably one of
> the
> > better options (outputting to C++ with libraries).
> As far as I know, QB64 only runs on Intel 32/64 bit on Windows (Various
> versions), Linux, and MAC (Intel only) OS's.
> FreeBASIC (competitor to QB64) - can run on DOS (special version of
> FreeBASIC - I have used FreeBASIC DOS version with FreeDOS), as well as
> Windows and LINUX. Do not know if can run on ARM processors.

Well, I know that donkey.bas works on Rob Hageman's PC-BASIC, because I tested it just a moment ago.

PC-BASIC itself is written in Python though. I seriously considered getting PC-BASIC to run on MS-DOS/FreeDOS by way of some Python compiler — that was before Microsoft open-sourced (most of) their 1983 version of GW-BASIC.

I have not tried running donkey.bas under either QB64, or FreeBASIC, or BBC BASIC — but maybe I should.

Thank you!

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

> Hello Rugxulo, hello Richard,
>
> > > I think for modern platforms,
> > > QB64 is probably one of
> > the
> > > better options (outputting to C++ with libraries).
> > As far as I know, QB64 only runs on Intel 32/64 bit on Windows (Various
> > versions), Linux, and MAC (Intel only) OS's.
> > FreeBASIC (competitor to QB64) - can run on DOS (special version of
> > FreeBASIC - I have used FreeBASIC DOS version with FreeDOS), as well as
> > Windows and LINUX. Do not know if can run on ARM processors.
>
> Well, I know that donkey.bas works on Rob Hageman's
> PC-BASIC, because I
> tested it just a moment ago.
>
> PC-BASIC itself is written in Python though. I seriously considered
> getting PC-BASIC to run on MS-DOS/FreeDOS by way of some Python compiler
> — that was before Microsoft open-sourced (most of) their 1983 version
> of GW-BASIC.
>
> I have not tried running donkey.bas under either QB64, or FreeBASIC, or BBC
> BASIC — but maybe I should.
>
> Thank you!







I think I may be getting off-topic/misunderstanding this thread - so I wish to correct/update an earlier response from me ...

All the following is quotes from some people who have knowledge of running QB64 on a Pi

>>>To run QB64 on a Raspberry PI, you need to do a few things to QB64 in order to compile and run programs.

>>>Also, right now, QB64 will only run on a 32-bit running on the RPI. I haven't yet gotten it to work on 64-bit OS's. I am still researching if this is possible. It just might be a PI ARM issue. I am experimenting with settings in the ARM chip itself and GCC/G++ compiler options from the ARM technical documents I've obtained from the IEEE. Very few in my local chapter have had experience in the ARM, and none with QB64.

>>>However, there are a few issues that are part of the PI's ARM processor that cannot be easily fixed in QB64.

>>>Most programs will compile and run fine. Others will get one or both of the following issues:

1) Racing Conditions (can appear as SIG BUS errors)
2) Misaligned Addresses, or misaligned word errors (appears as SIG BUS errors)

>>>For the most part, identifying where the racing condition is occuring (you will need to do a gdb session to find out), a simple _DELAY .3 will fix it. Racing occurs when QB64 creates multiple threads, and since QB64 isn't really a multithreaded programming language (the backend C++ is), there can be issues.

>>>There are two ways to fix the misaligned address/word issue. One way is to use the -fsanatize compiler option. However, the better fix for most of these issues has been added to the common.h file provided. The code that fixes this and other non-x86 issues is:



>>>>We've had several folks get QB64 up and running on a Pi, which has an ARM processor. I've never had one for testing or playing around with, but from what I remember, the biggest change needed is to #define NOTX86, or something similar inside the C source and then compile. Do a search for installing on Pi, and you'll probably find what you're looking for to get things working (at least somewhat) for you. I think there may be some issues with data alignment, or some such, that would need to be tweaked, but that one define is the biggest change needed, from what I remember.


If the above quotes are "on-topic" for this thread - I can supply links which also has code-boxes and more details associated

> If the above quotes are "on-topic" for this thread - I can supply links
> which also has code-boxes and more details associated

I don't know who you are waiting for approval from - the thread starter (me) or some moderator/owner, but I personally don't care if a thread goes off the original topic. If that's what interests people - which is why they keep responding - go for it!

> Well, PDOS-generic, anyway.
>
> Commands date/time, copy, dir, type, exit are working.
>
> Works on ARM Chromebook, Android smartphone and Android netbook.
>
> https://github.com/jeanmarclienher/Pdos-PdAndro/releases/tag/rel0.7.0



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?

I have not read into the ARM side of things (and how to configure FreeBASIC to produce the required code) but I was wondering if using your work would be useful to me.

On studying the FreeBASIC forum: -


https://www.freebasic.net/forum/index.php

there are 962 matches of "ARM" and for me, so far, these two below are interesting reading

FreeBASICpi - Retro Rasberry PI image
https://www.freebasic.net/forum/viewtopic.php?t=29665


FreBASIC 1.09.0 Release
https://www.freebasic.net/forum/viewtopic.php?p=289214&hilit=ARM#p289214

The complete lack of standardization of the ARM platform is a real problem, nothing FB devs can do anything about. This isn't Linux's fault per se. Every ARM device has its own variation on the boot loader, custom device tree, proprietary bits, etc. So there's no universal ARM Ubuntu distribution, for example, that runs on every device. Most custom devices like Pine's run their own distro that sometimes is based on something standard, but not always. So it's incredibly hard to support Linux binaries on ARM. If ARM ever finally got a standardized platform the way Intel-compatible PCs have with standardized booting, standardized device layouts, then Intel would be in serious trouble! Maybe if Microsoft would get serious about Windows on ARM then we'd see some standardization. Or Maybe Apple's M1 family will spur some of this.



There "might" be the option of using QB64 code program (generated for a PI) - but I have even less understanding on this (plus I do not have a PI).

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

If FreeBASIC is C90-compliant, then yes, it should work.

> The complete lack of standardization of the ARM platform is a real problem,
> nothing FB devs can do anything about. This isn't Linux's fault per se.
> Every ARM device has its own variation on the boot loader, custom device
> tree, proprietary bits, etc. So there's no universal ARM Ubuntu
> distribution, for example, that runs on every device. Most custom devices
> like Pine's run their own distro that sometimes is based on something
> standard, but not always. So it's incredibly hard to support Linux binaries
> on ARM. If ARM ever finally got a standardized platform the way
> Intel-compatible PCs have with standardized booting, standardized device
> layouts, then Intel would be in serious trouble! Maybe if Microsoft would
> get serious about Windows on ARM then we'd see some standardization. Or
> Maybe Apple's M1 family will spur some of this.

My design relies on something completely different.

I am sort-of dependent on the ARM syscalls being
standard, which I think they already are.

Even if they're not, I can get around that by having
a custom executable for just that non-standard device.

YOUR applications will work unchanged, because they
make NO syscalls and call NO DLLs.

That's what pdos-generic is.

Note that I tried it on 3 completely different devices
(chromebook, netbook, smartphone), and the syscalls, and
thus the applications (that don't make syscalls), all
worked fine.

Non-C90 applications can probably be made to work - C90
isn't magic - but probably require a lot of effort
setting up the required infrastructure to replace my
infrastructure.

Also, POC isn't completely complete yet. Maybe I'm
missing a concept that will be revealed later.

BFN. Paul.

> I'm not even after 1% binary compatibility. I'm after
> source code compatibility, and even willing to compromise
> on that depending on what the question is.

How is source code compatibility for MS-DOS being defined? DOS does not even expose a C API. It provides a system interface via interrupts, mainly 21H, accessible to X86 machine code. It is that system interface that is a main characteristic of MS-DOS and which compiler vendors faciliate to build their hopefully at minimum ANSI compatible C libraries around.

For my opinion, if you don't provide that interface you may call your software a DOS, but not MS-DOS.

Beside of that, have fun programming

Bernd

> > I'm not even after 1% binary compatibility. I'm after
> > source code compatibility, and even willing to compromise
> > on that depending on what the question is.
>
> How is source code compatibility for MS-DOS being defined? DOS does not
> even expose a C API. It provides a system interface via interrupts, mainly
> 21H, accessible to X86 machine code. It is that system interface that is a
> main characteristic of MS-DOS and which compiler vendors faciliate to build
> their hopefully at minimum ANSI compatible C libraries around.

Good question.

Step 1 is to define a C interface for MSDOS.

And then have source compatibility with that.

That's my current opinion, anyway. Happy to debate it.

My suggestion for the C interface is this:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/pos.h

But I'm open to negotiation on that too.

Note that Pos* was inspired by OS/2's Dos* which
I thought was neat.

> For my opinion, if you don't provide that interface you may call your
> software a DOS, but not MS-DOS.

When each of those C functions match directly onto
a documented MSDOS interrupt, in my opinion it is
MSDOS. If Microsoft had published that in say 1985,
would you call it MSDOS then?

The fact that Microsoft were slackos is no reason
to invalidate the moniker, in my opinion.

BFN. Paul.

> When each of those C functions match directly onto
> a documented MSDOS interrupt, in my opinion it is
> MSDOS. If Microsoft had published that in say 1985,
> would you call it MSDOS then?

For my opinion: no. Even in 1985 there were already different more or less compatible versions of DOS. Even the ones highly compatible did not call themself MS-DOS, at maximum MS-DOS compatible.

For me MS-DOS is a term referring to the original Microsoft codebase and binaries.

But I see in the codebase

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/int21.c

that there is already some int21 handler stuff. Perhaps it will eventually be some sort of binary compatible. At the moment FCB functions are missing though .

> Would you have said that CP/M-86 (a real thing)
> is not "real CP/M" because it doesn't run CP/M

Sorry, but we receive this answer - no body want pay for CP/M-86.

> 8080 binaries?

Why NEC V10/V20 have built-in 8080 emulation?
Why ZX Spectrum (with z80 CPU) impossible became to business area ?

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> > I suggest coming back when you can run Norton Commander or any of its
> > clones; no matter if on ARM or X86.
> A "DOS-like" OS on the ARM does sound exciting and enchanting. I appreciate
> your work and effort toward that end. We all start somewhere, and with ARM
> processors becoming more and more used, probably soon to 'replace' Intel
> chips due to reduced instruction set and scalability, we'll be "forced" to
> abandon Intel artechicture soon. So, "MS-DOS for ARM" is most welcomed,
> indeed.

(just a note:
Afaik it is not the reduced instruction set itself that makes ARM and related risc(v)'s interesting again. Anything ARM that can compete with modern x86 has had umpteen extensions since and is not exactly reduced any more.

It is the related but not 100% equal fact that this leads to instructions having an uniform size (or at least the basic units are the same size, more complex instructions might occupy multiple units).

This makes it easier to solve instruction decoding by parallelizing, and a better scheduler makes widening (extra executions units) easier. x86 with its uneven instructions makes the start of the next instruction dependent on all the ones before, and fixing that adds complexity in circuitry that already runs at the highest possible clocks.

But never underestimate the compatibility factor of x86. The software long tail should not be underestimated.
)

> Get Xtree Gold running on the ARM, and I'll be impressed! This is the
> "best" file manager / viewer / utility for DOS ever made, in my opinion. I
> still use it daily, and its interface is perfect.

I don't want to get in flamewars with Kerravon again, but his posix analogy falls flat on its face(Dos, unlike Unix, never had a source based application distriution model), and then unrelated 32-bit systems like OS/2 , Windows and even (classic) MacOS and Amiga (with x86 cards) are more compatible than his Dos. So why bother choosing it ?

> For my opinion, if you don't provide that interface you may call your
> software a DOS, but not MS-DOS.

IMO, if it's not written by the programmers at MicroSoft...
it _cannot_ by any stretch of the imagination be called MS-DOS

>
> Beside of that, have fun programming
>


Yes... have fun. :)

---
--
http://glennmcc.org/

> > When each of those C functions match directly onto
> > a documented MSDOS interrupt, in my opinion it is
> > MSDOS. If Microsoft had published that in say 1985,
> > would you call it MSDOS then?
>
> For my opinion: no. Even in 1985 there were already different more or less
> compatible versions of DOS. Even the ones highly compatible did not call
> themself MS-DOS, at maximum MS-DOS compatible.

Sure. That is technically correct, and you can
say the same about PC-DOS too.

> For me MS-DOS is a term referring to the original Microsoft codebase and
> binaries.

So MSDOS 5.0 is not real MSDOS, only MSDOS 1.0 is?

Any behavior change, including bug fixes, and including
applications with wild pointers pointing to a specific
byte in MSDOS 1.0 that allows the application to work,
but can't tolerate any change, is a non-MSDOS?

> But I see in the codebase
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/int21.c
>
> that there is already some int21 handler stuff. Perhaps it will eventually
> be some sort of binary compatible. At the moment FCB functions are missing
> though .

PDOS/86 is already binary compatible with some
MSDOS applications.

But PDOS/86 only really exists as a curiosity. I'm
more interested in source code compatibility, for
C programs.

And that requires that you first have a C interface,
which Microsoft didn't supply.

Nor did IBM supply, and it was IBM who was first, with
PC-DOS, wasn't it?

Given that neither IBM nor Microsoft are interested in
enhancing "DOS" to give a decent C API that allows
(moving forward) MSDOS to be ported to other platforms
(I think Microsoft does do that for Windows though),
why shouldn't we/I fill in this market gap?

And once the market gap is filled, we can then port
to ARM etc.

I've already got POC well underway to prove that this
is possible.

BFN. Paul.

> I don't want to get in flamewars with Kerravon again, but his posix analogy
> falls flat on its face(Dos, unlike Unix, never had a source based
> application distriution model),

Never, until now?

Is there a problem starting late?

Ever heard the expression "better late than never"?

> and then unrelated 32-bit systems like OS/2
> , Windows and even (classic) MacOS and Amiga (with x86 cards) are more
> compatible than his Dos. So why bother choosing it ?

Good question.

What are you trying to achieve?

Currently I'm running MSDOS source code on 32-bit ARM.

I don't have an x86 card on my Android phone, so the
solution I am currently using works best for me.

If you have an x86 card on your Android phone, by all
means, use it.

I'm not sure why an x86 card is superior though. It
would be superior if you were trying to run MSDOS
binaries unchanged. But I personally am happy to
recompile, and get much more than 1 MB of memory too.

If you're not happy to recompile, by all means, stay
with your x86 card, and stay in 1 MB.

You could argue that I'm the only person in the entire
world happy to recompile my MSDOS software. That may
be true, I have no way of knowing. But that is 1, not 0.

BFN. Paul.

> > Would you have said that CP/M-86 (a real thing)
> > is not "real CP/M" because it doesn't run CP/M
>
> Sorry, but we receive this answer - no body want pay for CP/M-86.

0 sales worldwide in history? I doubt that, but
if you have proof of that, I would be happy to
buy a copy myself in order to invalidate that
claim going forward.

But I don't understand the point of the claim.
Even if there are 0 sales, the software exists.
Are you saying it isn't "real" because it has
exactly 0 sales?

> > 8080 binaries?
>
> Why NEC V10/V20 have built-in 8080 emulation?

Maybe they saw a market opportunity? I don't know.
Is it relevant?

> Why ZX Spectrum (with z80 CPU) impossible became to business area ?

I don't know that either.

I also don't know why Windows 11 is called Windows
when it doesn't run 16-bit Windows 1.0 applications
(I think).

Does it matter? If so, why?

BFN. Paul.

> > For my opinion, if you don't provide that interface you may call your
> > software a DOS, but not MS-DOS.
>
> IMO, if it's not written by the programmers at MicroSoft...
> it _cannot_ by any stretch of the imagination be called MS-DOS

You could also argue that if it uses the radically
different (compared to 1.0) MSDOS 2.0 API, it isn't
"real" MSDOS either.

The fact is, Microsoft themselves changed the API
and still called their product MSDOS, even when
applications had zero chance of running under
original MSDOS.

I have done something far less than that - I've
provided very small C wrappers to many of the
MSDOS 2.0 (not 1.0) APIs.

Regardless - is there a point to this debate?
Is it just semantic? Because Microsoft abandoned
MSDOS (before IBM abandoned PCDOS by the way),
we should all freeze in time and not move
forward with MSDOS/PCDOS enhancements or
standardization efforts?

I guess that's what I'm after - a standardization
effort for (MS/PC/DR/P)DOS similar to what happened
for Unix. With a view to an eventual ARM port
(noting that Unix was ported to ARM too).

The fact that not many people are interested in
standardizing DOS, and most of them are in this
forum, does not deter me.

BFN. Paul.

> > Sorry, but we receive this answer - no body want pay for CP/M-86.
> 0 sales worldwide in history?

No. More then zero, but dos is win.

> > > 8080 binaries?
> > Why NEC V10/V20 have built-in 8080 emulation?
> Maybe they saw a market opportunity? I don't know.
> Is it relevant?
> > Why ZX Spectrum (with z80 CPU) impossible became to business area ?
> I don't know that either.

z80 can run 8080 binary code without changes.

CP/M-80 has two key-point:

1. 8080 (or z80) CPU
2. 80x25 text mode.
(??) 3. Floppy drive

If you broke one of them - will be fail. Yes, screen resolution is important (in old time). You "want" just change CPU arch.
ZX Spectrum has z80, but have no 80x25 text mode => cant run business software => never leave home-pc market. Japanese market is more lucky - with MSX2 they made escape and can run native CP/M-80 software.

Very expensive monitors can show 80x25 text. Home monitors TV can show ~40x25 text. First IBM PC want have support software for both of them.

Many CP/M-80 software is closed-source. Many articles in press - for example Dr Dobb magazine had own community (Tiny Basic, Small C came from this gang). Many free programs is shared as hex code listing in magazines and books. Community create free programming toolchain for CP/M-80. ALL this software, magazines is trash for CP/M-86. What is CP/M-86 without CP/M-80 software library? Nothing. For me, looks like community and companies lost interest and make dos-ports of software instead CP/M-86.

For other platform (not sure for IBM PC), people buy isa card's with 8080/z80 cpu to have possibility run exists native CP/M-80 software. With NEC CPU they can don't buy it.

So... CP/M-86 is true CP/M, from the point of view of the law (one TM-owner). But, imho, less notable because have different software library. Yes, DR continue create something new, but they lost market when market switch 80->86.

PS: About magazines. It is not so small "software collection" for investigation. I can recommend read "Dr Dobbs Journal of Computer Calisthenics and Orthodontia" has ~6 vol (i am mad and have all of them in paper) ~400-500 pages each. For example - vol1. (also is published monthly small magazines, this is big - looks like yearly content)

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> Regardless - is there a point to this debate?

Sorry to have gotten you riled-up... I was just joking around.

---
--
http://glennmcc.org/

> > Regardless - is there a point to this debate?
>
> Sorry to have gotten you riled-up... I was just joking around.

I'm not riled up.

Just interested in this topic.

BFN. Paul.

There is a new release.

Ignore the message that says "not working". It
works intermittently, which was true of the
previous release(s) too.

You can now use "cd" and traverse the entire
disk from the beginnings of an MSDOS prompt.

The final missing piece for POC is to get
pcomm to launch other a.out ARM executables.

That should be doable, but I need to think
about it some more, and I also need to pause
to consolidate with Jean-Marc.

BFN. Paul.

Direction for PDOS-generic went in an unexpected direction.

The pseudo-bios morphed into a shell plus loader, so a
separate command processor is not required. But you can
launch one if you want.

And I ordered a Pinebook Pro so that I could have an
actual laptop.

I sorted out some issues and have now released UCARM
at http://pdos.org

This is a "University Challenge" distribution, but unlike
the others, includes copyrighted tools (gcc and binutils),
as I don't have public domain versions of them.

I'm not aware of any other (ie non-x86) commercially available
laptop other than the Pinebook Pro.

If you have a Raspberry Pi you can use that instead, but
that's not a laptop.

So - you have the makings of an MSDOS prompt and you can
write C programs using the included SubC.

gccarm is also included, which is a better compiler, but
it uses floating point so this 32-bit software doesn't
work on real 64-bit hardware (not mine anyway - not sure
if it is possible to get a 32-bit floating point
accelerator emulator). Works fine on qemu-arm though.

microemacs is included too.

I should be able to include other C90 software as well,
like bwbasic, if someone is interested in something
specific. Mainly I just haven't started compiling
everything (hexdump etc) as I am pausing to see what
direction to take.

> And I ordered a Pinebook Pro so that I could have an
> actual laptop.
>
> I sorted out some issues and have now released UCARM
> at http://pdos.org
>
> This is a "University Challenge" distribution, but unlike
> the others, includes copyrighted tools (gcc and binutils),
> as I don't have public domain versions of them.
>
> I'm not aware of any other (ie non-x86) commercially available
> laptop other than the Pinebook Pro.

My brother has an ARM Chromebook, but I forget the specs.

There's also this:

Acer Aspire 1 ARM Laptop Has Nearly Complete Upstream Linux Support

A two-year old Qualcomm Snapdragon with 4 GB of RAM and 64 GB of
storage that can be bought refurbished for roughly $250.

And Darek Mihocka bought a Lenovo Yoga from Best Buy in 2018 for $700.

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.

> > And I ordered a Pinebook Pro so that I could have an
> > actual laptop.
> >
> > I sorted out some issues and have now released UCARM
> > at http://pdos.org
> >
> > This is a "University Challenge" distribution, but unlike
> > the others, includes copyrighted tools (gcc and binutils),
> > as I don't have public domain versions of them.
> >
> > I'm not aware of any other (ie non-x86) commercially available
> > laptop other than the Pinebook Pro.
>
> My brother has an ARM Chromebook, but I forget the specs.

I have an old ARM Chromebook too, but only 16 GiB
hard disk. I'm looking for a source of new computers.

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

Actually - thanks for that idea!

My situation has changed, so I may well be able to
use a Mac laptop.

In fact, that's exactly the situation I was in in
the 1980s. I thought the Amiga was technically
superior to the PC, and that if only PC programmers
wrote their code in standard C, we could switch
over to the Amiga.

Now it is Windows software that can be written in
C90 and recompiled for the Mac as a PDOS-generic
app, running in what looks like an MSDOS prompt.

Sounds like my new calling in life.

BFN. Paul.

New version just released:

https://github.com/o-ksi-d/Pdos-PdAndro/releases/tag/rel0.57.0

Combine that with ucarm.zip from http://pdos.org and
you now have a C90 compiler (gccarm - a modified gcc 3.2.3).

I also have the start of a gcca64.zip available.

A question though.

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.

It's very fast to compile C programs regardless.
Given that this is now running native ARM.

So - is this the new DOS? If Microsoft had ported
MSDOS to the ARM processor, would that be possible
and legitimate?

ie why are people here running DOS - for the
simplicity? Is this the equivalent? If you
write your programs in C90 they are actually
portable to anywhere. So basically everything
is MSDOS if you stick to C90.

BFN. Paul.


P.S. 64-bit ARM and x64 is starting now too as proof
of concept - can be obtained from the same place as
UCARM at http://pdos.org

Hi Paul,

> So - is this the new DOS? If Microsoft had ported
> MSDOS to the ARM processor, would that be possible
> and legitimate?
>
> ie why are people here running DOS - for the
> simplicity? Is this the equivalent? If you
> write your programs in C90 they are actually
> portable to anywhere. So basically everything
> is MSDOS if you stick to C90.

When I have DOS binaries already, I would not recompile them for another processor type. Even for open source DOS binaries, I would be too lazy, given that you can run existing DOS and/or PC emulators on ARM-based operating systems which also emulate a classic x86 CPU. Note that DOS apps do not usually need much CPU speed, so the emulation speed loss is no big problem.

Of course you would save some energy by using apps compiled for native ARM, but then I would already have many native Linux or other apps for ARM in that case and again no need for a special DOS version running natively on ARM itself.

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.

---
FreeDOS / DOSEMU2 / ...

> When I have DOS binaries already, I would not recompile them for another
> processor type. Even for open source DOS binaries, I would be too lazy,
> given that you can run existing DOS and/or PC emulators on ARM-based
> operating systems which also emulate a classic x86 CPU.

Given that most "open source" apps are a pain in the neck to recompile (if not downright impossible), I don't blame you. It takes a surprising amount of work to make things easy for end users (but it's worth it, IMHO).

I've wondered about bytecode / p-code lately. Usually it's slower, but it's at least neutral. Maybe compiling to bytecode for redistribution then the end users can optionally recompile to native code with localized tools. (No, I don't mean LLVM.)

> Note that DOS apps do not usually need much CPU speed,
> so the emulation speed loss is no big problem.

I disagree with this. I've seen significant slowdown with software emulation (and bugs). For "normal" apps it's okay. But there are a lot of apps which are painfully slow (e.g. DJGPP, but often even 16-bit is slow as molasses). Fast emulation is possible, but few care.

However, MS emulates x86 (and x64?) apps on ARM64 Windows, so it's not a bad idea. (Supposedly they also support DirectX 9-12.)

> Of course you would save some energy by using apps compiled for native ARM,
> but then I would already have many native Linux or other apps for ARM in
> that case and again no need for a special DOS version running natively on
> ARM itself.

IBM is one of the biggest businesses in the world and commercially supported DOS for over 20 years. It's not so much times changed: people changed. It's more their personal taste than raw technical requirements.

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

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

> > When I have DOS binaries already, I would not recompile them for another
> > processor type. Even for open source DOS binaries, I would be too lazy,
> > given that you can run existing DOS and/or PC emulators on ARM-based
> > operating systems which also emulate a classic x86 CPU.
>
> Given that most "open source" apps are a pain in the neck to recompile (if
> not downright impossible), I don't blame you. It takes a surprising amount
> of work to make things easy for end users (but it's worth it, IMHO).

Right. My goal is to provide the essential binaries
for development.

And then we'll see where we go from there.

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

(I may be doing that too - it's not clear to me
what I am trying to do - the latest thought was
that PdAndro might be useful to blind people -
especially people wanting to learn programming -
who can't see graphics, but with the Android
able to give the voice support).

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

Thanks. Paul.