DOS ain't dead

There is a Freedos64 project but I'm not sure what the status is.

The important things are:

1. The concept of 64-bit DOS exists.

2. It will necessarily involve recompiling all executables.

As such, I have my own definition of "64-bit DOS" and tentative executable format.

It's available from the "EFI booting" section of http://pdos.org

It runs PDOS-generic (x64 flavor) instead of PDOS/386.

It uses the COFF executable format.

The API is still the MSDOS-inspired Pos* interface used by PDOS/386.

Note that PDOS-generic is still proof of concept, so it doesn't have the same functionality that PDOS/386 (or MSDOS) has.

Note that other people seem to have a definition of "32-bit DOS" as "must be one of the existing DOS-extender formats so that no executable needs to be recompiled". I don't know whether a 64-bit DOS extender format already exists and is set in stone and the first 5 or whatever people who created one set the definitive set of standards and there can't be a 6th format added, such that those 5 are all legitimate but mine can never be legitimate.

BFN. Paul.

I think 64bit DOS has quite low importance. There already was established XMS extension to access >4GB memory using HIMEMSX. And it also needs to rework current programs to utilitze this extra memory. There are not so many such new apps - I know about only 2, the modified ramdisk and HDAplay. And there's aslo 64-bit NDN DOS version (but it excludes usage in v86 mode). Maybe someone will find a special use case for utilize >4GB memory but recent years didn't show much interesting in this field.

---
DOS gives me freedom to unlimited HW access.

> As such, I have my own definition of "64-bit DOS" and tentative executable
> format.
>
> It's available from the "EFI booting" section of http://pdos.org

Note that that original is in the UCX64 section and
it now runs certain (basically 64-bit msvcrt.dll-based
applications) on a 64-bit UEFI system.

UEFI and Win64 use the same function calling convention
(rcx etc), which is how it manages to work.

x64 Linux uses a different function calling convention
(rdi etc), which I thought precluded the ability to do
the same trick on Linux (ie a very small pseudo-bios).

However, I figured out a way of doing it, that is some
sort of strange blend of Linux and Win64.

The end result is that you can run those perfectly
standard/normal Win64 executables on Linux now, and
instead of needing to download gigabytes of Wine
which turns out to be broken after all that effort,
all you need is a single ELF executable, 103k in size.

That is available as UCX64L in the UCARM (not UCX64)
section of pdos.org.

BFN. Paul.

Depending on what you're needing your software to do, you could simply get away with wrapping the EFI Protocol calls with Pos* calls and just run your programs directly under UEFI. The UEFI application environment provides pretty much all the same functionality that DOS itself once did.

> Depending on what you're needing your software to do, you could simply get
> away with wrapping the EFI Protocol calls with Pos* calls and just run your
> programs directly under UEFI. The UEFI application environment provides
> pretty much all the same functionality that DOS itself once did.

I don't even need the pos layer.

I am only interested in running C90 compliant programs.

So UEFI is just another API for my c library pdpclib

And any of my UEFI executables can handle being
called either via the UEFI shell
or directly booted.

But I prefer shipping windows executables