DOS ain't dead - DOS for 64 bits?

libz

17.10.2025, 23:37

DOS for 64 bits? (Users)

Hi all,

Maybe because I'm older now, I realize that focus is important. As is a distraction-free setup, as is speed of execution, as is simplicity.

DOS has all of this.
But everything I read about DOS is about the past.
16bit, 32bit, little RAM...

I don't know how to program in C or assembly, so I cannot help.
But could help in testing or in propaganda.

Would there be space for a DOS (like) for the present and for the future, that could use all the 64bit CPU, GBs (or even TBs) of RAM, with direct access to the hardware, that could beat all Windows and Linux in speed, simplicity and focus for the user?

kerravon

Ligao, Free World North,
18.10.2025, 10:34

@ libz

DOS for 64 bits?

Post reply

> Hi all,
>
> Maybe because I'm older now, I realize that focus is important. As is a
> distraction-free setup, as is speed of execution, as is simplicity.
>
> DOS has all of this.
> But everything I read about DOS is about the past.
> 16bit, 32bit, little RAM...
>
> I don't know how to program in C or assembly, so I cannot help.
> But could help in testing or in propaganda.
>
> Would there be space for a DOS (like) for the present and for the future,
> that could use all the 64bit CPU, GBs (or even TBs) of RAM, with direct
> access to the hardware, that could beat all Windows and Linux in speed,
> simplicity and focus for the user?

I believe UCX64 has all of that.

Available from https://pdos.org

Why do you want to directly access the hardware instead of doing
a UEFI call though? MSDOS did the same thing - a BIOS call.

Regardless, you can do either - even as an application.

But - like with MSDOS - you're officially supposed to do an INT 21H
call to access MSDOS services - but in UCX64 the INT 21H has been
replaced by a callback function instead. It probably could be done
via INT 21H though - if that served some purpose.

BFN. Paul.

kerravon Ligao, Free World North, 18.10.2025, 10:38 @ kerravon	DOS for 64 bits? Post reply
	Also, technically you don't even need to use UCX64. Just write UEFI shell programs. The advantage of UCX64 is that it allows you to run (certain) Win64 executables. But within that - if you want to access the hardware - go right ahead.

kerravon

Ligao, Free World North,
18.10.2025, 11:03

@ kerravon

DOS for 64 bits?

Post reply

> Also, technically you don't even need to use UCX64.
>
> Just write UEFI shell programs.
>
> The advantage of UCX64 is that it allows you to run (certain) Win64
> executables.

Also note that UCX64 comes with PDPCLIB, which contains
everything you need to write UEFI shell programs, if you
wish to go that route.

Or you can run those same tools on Linux or Mac - x64 or ARM64.
Or Win32 or Linux32 - ARM or x86.

I'm currently missing 32-bit MacOS support.

I have Motorola 68000 support, but it's not good enough to
produce x64 code - if you wanted to do that for fun. Same
applies to ARM32. ie you can't target x64 from ARM32 - I
don't have the required 64-bit support. But I may be able
to twist some arms to stop this requirement for 64-bit values
in the first place.

libz

22.10.2025, 22:00

@ kerravon

DOS for 64 bits?

Post reply

Hello kerravon,

Yes, I've been at https://www.pdos.org/ before.
I've read all of it, including some other texts by you and we have some common thoughts in several themes.

But I'm not a system programmer and I'm not at a level of knowledge that I can take what I read at the website and conclude that pdos is a DOS like system where I could run x86_64 applications.
I didn't get that idea before, and I hardly get it now.
The programming I do is about business data and associated areas. No C, or assembly.

The most relevant section for this seems to be 'University Challenge x64'
So, what I miss is a tutorial where it could be shown step by step what to do to have pdos booting in a x86_64 hardware (and in other ones as well).
I'm unaware of what could be done using EFI. It seems that you've programmed pdos to run as a UEFI module, is that correct?
Can pdos run 64 bit programs and use GBs of RAM and big files?
Can pdos run all ancient MSDOS programs, like Turbo Pascal, Norton Commander, etc?

Some howtos and some videos would be of great help for me and for others like me that don't have your level of expertise in the subject.
I know, I know, it's a lot of work that I'm asking.

Thank you,
All the best.

kerravon

Ligao, Free World North,
23.10.2025, 04:16

@ libz

DOS for 64 bits?

Post reply

> The most relevant section for this seems to be 'University Challenge x64'
> So, what I miss is a tutorial where it could be shown step by step what to
> do to have pdos booting in a x86_64 hardware (and in other ones as well).
> I'm unaware of what could be done using EFI. It seems that you've
> programmed pdos to run as a UEFI module, is that correct?

Yes - I'm not sure "module" is the correct term, but I don't
know what the correct term is.

Modern x64 computers all use UEFI. It's very difficult to find
a BIOS now.

Do you want to run on real hardware or under Virtualbox etc?

I provide a VHD. You can use that directly in Virtualbox or
you can burn it to USB stick using Win32 Disk Imager. If
doing the latter I think you need to rename it to .img.

> Can pdos run 64 bit programs and use GBs of RAM and big files?

Theoretically it can be rebuilt to do that.

Currently it is mimicking Microsoft Windows and Microsoft
Visual C, which uses 32-bit long still - and that is what C90
gives.

So for now, no big files.

For big memory - a different issue - previously I was using
cc64 and that needed to be restricted to the lower 2 GiB.
I am now using mcc, but haven't fully migrated, so the
restriction remains.

> Can pdos run all ancient MSDOS programs, like Turbo Pascal, Norton
> Commander, etc?

It can't run any of them. You need to recompile for the x64
platform.

What did you expect when you asked for DOS to be 64-bit?

Genuine question - I'm interested in your opinion on the
very definition of "DOS". It's philosophy to me.

It will run some existing genuine Win64 x64 programs though
(mainly ones that I built).

But that is also a philosophical question - is the Win64 command
prompt "64-bit DOS" too?

> Some howtos and some videos would be of great help for me and for others
> like me that don't have your level of expertise in the subject.
> I know, I know, it's a lot of work that I'm asking.

I can guide you through it (in this forum, in text) if you start by
telling me where you want to run it. You can make a video at
the end of that process if you wish. Or a HOWTO. You offered
to do something non-programming for the "64-bit DOS", right?

kerravon Ligao, Free World North, 23.10.2025, 04:29 @ kerravon	DOS for 64 bits? Post reply
	> you can burn it to USB stick using Win32 Disk Imager. If > doing the latter I think you need to rename it to .img. I think I remember now - the trick is to choose "all files", otherwise "vhd" isn't visible. It's Bochs on Android that may require you to rename the vhd to img.

kerravon

Ligao, Free World North,
23.10.2025, 05:59

@ kerravon

DOS for 64 bits?

Post reply

> What did you expect when you asked for DOS to be 64-bit?

Just a bit more on the philosophy.

The traditional MSDOS interface was defined in assembler,
with calls to INT 21H, that included some calls with parameters
given in segment registers.

It's not possible to reproduce that exactly in x64. You can't
manipulate segment registers like that, and it defeats the
purpose to use the exact same 16-bit registers - you need
to upgrade to 64-bit registers.

So. Existing assembler source needs to change.

And most people - even on MSDOS - were writing in C, not
assembler, anyway.

And if existing assembler source needs to change - then what
is "acceptable" to get the "DOS" label?

Also - is there a particular reason to want that exact label?
What's the underlying objective?

And if the original source is written in C - particularly if it
conforms to the C90 standard - then yes, that "DOS program"
will work on 64-bit "DOS" too.

It will also work on any machine that is called "definitely not DOS".

So at some point, I get lost.

Being lost in terminology doesn't prevent me from getting
software to run though.

libz

27.10.2025, 12:07

@ kerravon

DOS for 64 bits?

Post reply

Hi kerravon,

My answers are interlined in yours, below.

> > The most relevant section for this seems to be 'University Challenge
> x64'
> > So, what I miss is a tutorial where it could be shown step by step what
> to
> > do to have pdos booting in a x86_64 hardware (and in other ones as
> well).
> > I'm unaware of what could be done using EFI. It seems that you've
> > programmed pdos to run as a UEFI module, is that correct?
>
> Yes - I'm not sure "module" is the correct term, but I don't
> know what the correct term is.
>
> Modern x64 computers all use UEFI. It's very difficult to find
> a BIOS now.
>
> Do you want to run on real hardware or under Virtualbox etc?
I have several low powered thin computers that are able to run both BIOS and UEFI.
UEFI is the future so I'm fine with using it from the time being, and can use one of them to run PDOS.
So, I'm interested in running in real hardware, although can test in a virtual host before, for convenience.

> > Can pdos run 64 bit programs and use GBs of RAM and big files?
>
> Theoretically it can be rebuilt to do that.
>
> Currently it is mimicking Microsoft Windows and Microsoft
> Visual C, which uses 32-bit long still - and that is what C90
> gives.
>
> So for now, no big files.
>
> For big memory - a different issue - previously I was using
> cc64 and that needed to be restricted to the lowerpdos 2 GiB.
> I am now using mcc, but haven't fully migrated, so the
> restriction remains.
Ok, for the time being.

> > Can pdos run all ancient MSDOS programs, like Turbo Pascal, Norton
> > Commander, etc?
>
> It can't run any of them. You need to recompile for the x64
> platform.
Ok.
I'll have some work to do, then!

> What did you expect when you asked for DOS to be 64-bit?
>
> Genuine question - I'm interested in your opinion on the
> very definition of "DOS". It's philosophy to me.
Ah, ah, my definition will be short in scope to your expectations, I guess.
DOS for me is what I recall my experience has been in the past where I used MS-DOS, DR-DOS and I think 4DOS. So, something close to that.
I've read that 4DOS is public domain.
Have you compiled it to PDOS?

>
> It will run some existing genuine Win64 x64 programs though
> (mainly ones that I built).
>
> But that is also a philosophical question - is the Win64 command
> prompt "64-bit DOS" too?
In my point of view, I don't consider it a DOS as it's some indirect interaction with the hardware.

> > Some howtos and some videos would be of great help for me and for others
> > like me that don't have your level of expertise in the subject.
> > I know, I know, it's a lot of work that I'm asking.
>
> I can guide you through it (in this forum, in text) if you start by
> telling me where you want to run it. You can make a video at
> the end of that process if you wish. Or a HOWTO. You offered
> to do something non-programming for the "64-bit DOS", right?
Yes, I'll do it, at a very slow pace, but I'm interested.
So, to begin with, copy the ucx64.zip (unzipped) or the pdos.zip to the UEFI partition and boot from there, right?
Are the two ucx64 and pdos systems at the same level of development, or which one is more advanced for me to try?
Given what you said above regarding the limitations of the 64 bit version, can it be considered to be equally constrained at the 32 bit word and 2GB of RAM?

Best regards.

kerravon

Ligao, Free World North,
27.10.2025, 13:17

@ libz

DOS for 64 bits?

Post reply

> I have several low powered thin computers that are able to run both BIOS
> and UEFI.
> UEFI is the future so I'm fine with using it from the time being, and can
> use one of them to run PDOS.
> So, I'm interested in running in real hardware, although can test in a
> virtual host before, for convenience.

Ok.

> > > Can pdos run all ancient MSDOS programs, like Turbo Pascal, Norton
> > > Commander, etc?
> >
> > It can't run any of them. You need to recompile for the x64
> > platform.

> Ok.
> I'll have some work to do, then!

The chances of any of those things being C90-compliant are
close to zero, so it's not just a recompile that is required.

> > What did you expect when you asked for DOS to be 64-bit?
> >
> > Genuine question - I'm interested in your opinion on the
> > very definition of "DOS". It's philosophy to me.

> Ah, ah, my definition will be short in scope to your expectations, I
> guess.
> DOS for me is what I recall my experience has been in the past where I used
> MS-DOS, DR-DOS and I think 4DOS. So, something close to that.

You can get very close to the MSDOS command prompt from
the Windows 11 command prompt. You can probably even
configure the latter to be identical.

> I've read that 4DOS is public domain.

https://en.wikipedia.org/wiki/4DOS

It's copyrighted (modified MIT), not public domain, according
to that.

> Have you compiled it to PDOS?

I'm personally not willing to work on copyrighted software
unless I'm being paid full western contract rates.

I make some limited exceptions as a means to an end, and
the end is to have completely public domain software so
that I can fix anything I want, and it isn't owned by someone
else who wrote the buggy software in the first place.

> > It will run some existing genuine Win64 x64 programs though
> > (mainly ones that I built).
> >
> > But that is also a philosophical question - is the Win64 command
> > prompt "64-bit DOS" too?

> In my point of view, I don't consider it a DOS as it's some indirect
> interaction with the hardware.

How do you actually know that? First of all, the MSDOS command
prompt (command.com) doesn't directly access the hardware - it
does calls to the MSDOS OS proper (msdos.sys). And even that
doesn't access the hardware directly, it does BIOS calls.

(As far as I am aware, anyway - now that we have the MSDOS 4.0
source code we can find out for sure - but that in itself defeats
the whole purpose of finding out in the first place - if it's not
possible to detect as an end user, and you have to spend an
awful lot of effort to prove that - what difference does it make?).

You could argue that MSDOS apps can CHOOSE to access the
hardware directly if they want - well - that's largely because the
processor itself doesn't have a way of stopping you - and that's
not necessarily a good thing. Can you tell me why you think that
would be a good thing? Getting some sort of hardware demo
started quickly - even if MSDOS crashes a lot while attempting
to demo that?

If that is the "target market" - then there are still alternatives -
like creating an extension to the MSDOS API that allows you to
write "directly" to an I/O port.

Or what about if the Windows 11 command prompt operated in
ring 0 - would you be happy then? Do you need it to bypass
virtual memory too? The PDOS "Windows clones" don't use
virtual memory - so that could be what you're after - bypass
the complication of virtual memory.

That's what I was after, basically/sort of.

> > > Some howtos and some videos would be of great help for me and for
> others
> > > like me that don't have your level of expertise in the subject.
> > > I know, I know, it's a lot of work that I'm asking.
> >
> > I can guide you through it (in this forum, in text) if you start by
> > telling me where you want to run it. You can make a video at
> > the end of that process if you wish. Or a HOWTO. You offered
> > to do something non-programming for the "64-bit DOS", right?

> Yes, I'll do it, at a very slow pace, but I'm interested.
> So, to begin with, copy the ucx64.zip (unzipped) or the pdos.zip to the
> UEFI partition and boot from there, right?

Not really.

You mentioned you were interested in running on a virtual host
before putting it on a real computer.

So start with that. Which virtual host are you interested in using?
I support both Oracle Virtualbox and qemu.

In both cases, you just point it to the VHD (hard disk image)
within the zip file.

UCX64 you need to go to the extra effort of enabling UEFI (a
checkbox in Virtualbox, but qemu is a bit more complicated).

Note that on real hardware, you could indeed unzip ucx64.vhd
(not .zip) onto a "UEFI partitition". But pdos.vhd needs to be
burned as an image - you can't just unzip it.

> Are the two ucx64 and pdos systems at the same level of development, or
> which one is more advanced for me to try?

The BIOS-based PDOS/386 is the most advanced.

But the future is expected to be UCX64 for a different reason -
the public domain C compiler (mcc) now available.

> Given what you said above regarding the limitations of the 64 bit version,
> can it be considered to be equally constrained at the 32 bit word and 2GB
> of RAM?

Yes, both are equally constrained in RAM currently.

But one of the reasons I am in this "DOS Ain't Dead" forum in the first
place is because I believe the software industry went into a dead end,
and I want to start again with 640k of RAM and negotiate why we need
an increase from that.

If 2 GB is a constraint for you, you might want to rethink your life choices. :-)

Here is something someone else wrote:

https://www.quora.com/Why-did-you-leave-a-job-as-a-software-engineer/answer/Jeff-Sturm-2

His "solution" was to leave the industry.

My "solution" involves a return to MSDOS - or something similar.

EDIT: I forgot to mention - I completely rewrote pdos.org from scratch to explain what the current situation is with PDOS. Previously it was created in an adhoc manner as breakthroughs happened in a fairly random fashion.