DOS ain't dead

I think some of you may be interested in the Cosmopolitan project, aiming for a common ABI on x86-64: so far, Linux, Win64, *BSD work, and there is some support for bare metal as well; I think DOS64 might be another platform.

> I think some of you may be interested in the
> Cosmopolitan project, aiming
> for a common ABI on x86-64: so
> far, Linux, Win64, *BSD work, and there is some support for bare metal as
> well; I think DOS64 might be another platform.

Q: Has anyone ever even attempted to create an actual 64bit DOS kernel ?

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

> > I think some of you may be interested in the
> > Cosmopolitan project,
> aiming
> > for a common ABI on x86-64: so
> > far, Linux, Win64, *BSD work, and there is some support for bare metal
> as
> > well; I think DOS64 might be another platform.
>
> Q: Has anyone ever even attempted to create an actual 64bit DOS kernel ?

Not exactly, but Andreas Grech ("Japheth") wrote a minimal DOS64-stub

> > I think some of you may be interested in the
> > Cosmopolitan project,
> aiming
> > for a common ABI on x86-64: so
> > far, Linux, Win64, *BSD work, and there is some support for bare metal
> as
> > well; I think DOS64 might be another platform.
>
> Q: Has anyone ever even attempted to create an actual 64bit DOS kernel ?

fdpp is called a 64-bit DOS. It is based on the FreeDOS kernel and provides the normal (Real/Virtual 86 Mode) DOS environment from C++ code that is compiled into a 64-bit library. It can only be used as a plugin for a specific machine setup, currently only dosemu2.

---
l

> It is based on the FreeDOS kernel and provides the normal (Real/Virtual 86
> Mode) DOS environment from C++ code that is compiled into a 64-bit library.

How it provides V86 mode when running in 64 bit mode?

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

> > It is based on the FreeDOS kernel and provides the normal (Real/Virtual
> 86
> > Mode) DOS environment from C++ code that is compiled into a 64-bit
> library.
>
> How it provides V86 mode when running in 64 bit mode?\

I believe the kernel mainly runs in the userspace process of the dosemu2 instance, and interfaces with the 86 Mode of the dosemu2 machine. This can be true V86 on 32-bit hosts (so fdpp is actually 32-bit then), or it can use KVM or its CPU emulator to run the DOS applications. dosemu takes care to set up the environment.

---
l

> > > I think some of you may be interested in the
> > > Cosmopolitan project,
> > aiming
> > > for a common ABI on x86-64:
> so
> > > far, Linux, Win64, *BSD work, and there is some support for bare metal
> > as
> > > well; I think DOS64 might be another platform.
> >
> > Q: Has anyone ever even attempted to create an actual 64bit DOS kernel ?
>
> fdpp is called a 64-bit DOS. It
> is based on the FreeDOS kernel and provides the normal (Real/Virtual 86
> Mode) DOS environment from C++ code that is compiled into a 64-bit library.
> It can only be used as a plugin for a specific machine setup, currently
> only dosemu2.

So, the 'short answer' to my query is... "no"

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

> So, the 'short answer' to my query is... "no"

Well, I have been trying to get something going that can boot from an x86-64 UEFI environment and, maybe at some point, usefully run 16-bit code.

It is still nowhere near complete though, partly because to do it properly I will need to understand ACPI, and the ACPI specification is more than 1,000 pages long.

(Meanwhile, as the Cosmopolitan author reminds us, long mode is long.)

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

> > So, the 'short answer' to my query is... "no"
>
> Well, I have been trying
> to get something going that can boot from an x86-64 UEFI environment and,
> maybe at some point, usefully run 16-bit code.
>
> It is still nowhere near complete though, partly because to do it properly
> I will need to understand ACPI, and the ACPI specification is more than
> 1,000 pages long.
>
> (Meanwhile, as the Cosmopolitan author reminds us,
> long
> mode is long.)

What mode do you (intend to) use to run 16-bit code? SVM or VTX?

---
l

Hello ecm,

> > Well, I have been
> trying
> > to get something going that can boot from an x86-64 UEFI environment
> and,
> > maybe at some point, usefully run 16-bit code.
> What mode do you (intend to) use to run 16-bit code? SVM or VTX?

For now, I am thinking of just using real mode (!). That is to say, the 16-bit code will run directly on the "bare metal" with no virtualization, and the CPU switches between real mode and 64-bit long mode as needed.

But perhaps this is not exactly a good idea...

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

I think it's problematic as when you boot UEFI it will persist in 32/64b pmode and all UEFI runtime services expect to be called in pomde. I don't know how UEFI CSM exactly work but I expect, when it is used, you cannot use UEFI runtime services then - thats disadvantge as you probably want to use advantage of existing UEFI drivers for storage, USB, gfx...

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

> I think it's problematic as when you boot UEFI it will persist in 32/64b
> pmode and all UEFI runtime services expect to be called in pomde. I don't
> know how UEFI CSM exactly work but I expect, when it is used, you cannot
> use UEFI runtime services then - thats disadvantge as you probably want to
> use advantage of existing UEFI drivers for storage, USB, gfx...


I was also under the impression that once you enter long mode, there’s no way to fault back into any other mode.

> > I think it's problematic as when you boot UEFI it will persist in 32/64b
> > pmode and all UEFI runtime services expect to be called in pomde. I
> don't
> > know how UEFI CSM exactly work but I expect, when it is used, you cannot
> > use UEFI runtime services then - thats disadvantge as you probably want
> to
> > use advantage of existing UEFI drivers for storage, USB, gfx...
>
>
> I was also under the impression that once you enter long mode, there’s no
> way to fault back into any other mode.

Why couldn't you force a triple-fault and get back to 32bit and / or 16 bit real mode that way? Couldn't one "fault" Ring 0?

After all of this time, nobody's figured out how to use DOS in a non-emulation mode / non-Virtual machine mode on a UEFI boot?

Is it really true that on a system without a true CSM legacy BIOS will be completely unable to access real mode or can we create some sort of compatibility wrapper in software as an abstraction layer in software to enable "bare metal" 16-bit DOS on such systems?

Anyway, what does a 64-bit DOS get us except the very important access to memory > 4GB natively and perhaps some modern drivers? Software would need to be written, and there's a dearth of such software!

> I was also under the impression that once you enter long mode, there’s no
> way to fault back into any other mode.

It's clearly documented how to switch between modes. To switch from long mode to real-mode is no problem at all. The only switches that aren't (directly) possible is from legacy 32-bit paging to PAE-paging and vice versa - because that requires to set both cpu registers CR3 and CR4 simultaneously.

---
MS-DOS forever!

Hello RayeR, Oso2k, and Zyzzle,

> Is it really true that on a system without a true CSM legacy BIOS will be
> completely unable to access real mode or can we create some sort of
> compatibility wrapper in software as an abstraction layer in software to
> enable "bare metal" 16-bit DOS on such systems?

As Japheth mentioned, yes, it is very much possible to switch from 64-bit long mode to real mode.

In fact Intel's own TianoCore UEFI implementation has some code to do just that. The CPU very much supports going from long mode to real mode. The problem in getting an "abstraction layer" working is mainly in the stuff outside of the CPU (again, ACPI... ).

Thank you!

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

> > So, the 'short answer' to my query is... "no"
>
> Well, I have been trying
> to get something going that can boot from an x86-64 UEFI environment and,
> maybe at some point, usefully run 16-bit code.
>
> It is still nowhere near complete though, partly because to do it properly
> I will need to understand ACPI, and the ACPI specification is more than
> 1,000 pages long.
>
> (Meanwhile, as the Cosmopolitan author reminds us,
> long
> mode is long.)

What I was meaning is...

Has anyone ever attempted to create an actual 64bit DOS ?

ie: compile Freedos's kernel.sys, command.com
and all other associated files as TRUE 64bit
just as the Linux kernel is now available as true 64bit.

And then of-course...
recompile any DOS programs in TRUE 64bit rather than 16bit or 32bit

My guess is... "nope".

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

Hello glennmcc,

> ie: compile Freedos's kernel.sys, command.com
> and all other associated files as TRUE 64bit
> just as the Linux kernel is now available as true 64bit.

That whole idea itself will not make very much sense.

(...and by "not make very much sense", I mean that it will be like trying to genetically engineer a non-equine horse.)

MS-DOS's system call interface is only described in terms of 16-bit assembly language constructs. Other than that, there is no stable interface between the OS kernel and application programs.

MS-DOS does not have a syscall() function (or a syscall(2) man page) which one can "simply" port to a different (sub)architecture.

Thank you!

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

OK, there is way to switch to RM and back but question is that UEFI runtime services are compatible with it and how many time it takes this overhead (saving context, etc) when switching back and forth too often. I guess that once you switch to RM and change some HW state then it will mess up UEFI when you switch back. I don't know if UEFI design was count with such option in it's architecture.

BTW on MBs without CSM it is still a possibility to compile opensource SeaBIOS as CSM and do BIOS mod to insert it in. But I didn't read any success story about it yet.

BTW2 maybe it would be easier to compile DosBox(X) as a native UEFI application that will use UEFI SVGA, input and storage drivers that you can select at boot. Of course it wouldn't be real DOS but I guess UEFI env. is some closer to linux so porting would be easier than messing with all the low level and sometimes undocumented stuff needed for real dos64. An it remembers me there already was/is RDOS project that is not much discussed anywhere - at least it contains some attempt to handle ACPI. But I was unable to boot it on my PC.

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

> Hello glennmcc,
>
> > ie: compile Freedos's kernel.sys, command.com
> > and all other associated files as TRUE 64bit
> > just as the Linux kernel is now available as true 64bit.
>
> That whole idea itself will not make very much sense.
>
> (...and by "not make very much sense", I mean that it will be like trying
> to genetically engineer a non-equine horse.)
>
> MS-DOS's system call interface is only described in terms of 16-bit
> assembly language constructs. Other than that, there is no stable
> interface between the OS kernel and application programs.
>
> MS-DOS does not have a syscall() function (or a syscall(2) man page) which
> one can "simply" port to a different (sub)architecture.
>
> Thank you!

Following that line of logic, it does not make very much sense to make a 32bit
DOS kernel (which if I recall correctly has been done a couple of times),
nor does it make very much sense to make a 64bit Linux kernel.

But anyways... my query was instigated by the original quip of...

"I think DOS64 might be another platform."

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

> Following that line of logic, it does not make very much sense to make a
> 32bit
> DOS kernel (which if I recall correctly has been done a couple of times),

In regard to 'have been done a couple of times', I wonder what you are referring to.
Unless you mean OS/2, Windows NT DOSBox or Linux QEMU are '32bit DOS kernels'

> > Following that line of logic, it does not make very much sense to make a
> > 32bit
> > DOS kernel (which if I recall correctly has been done a couple of
> times),
>
> In regard to 'have been done a couple of times', I wonder what you are
> referring to.
> Unless you mean OS/2, Windows NT DOSBox or Linux QEMU are '32bit DOS
> kernels'

Nope... I mean an ACTUAL 32bit DOS kernel

Don't know if this one is still under development or not but it was one of the attempts I had heard of a long time ago.

https://board.flatassembler.net/topic.php?t=12396

And here's another...

https://en.wikipedia.org/wiki/DexOS


There we go... downloaded the DexOS boot floppy and fired-it-up.

http://glennmcc.org/download/DexOS.mp4

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

Hello glennmcc,

> > MS-DOS does not have a syscall() function (or a syscall(2) man page)
> which
> > one can "simply" port to a different (sub)architecture.

> Following that line of logic, it does not make very much sense to make a
> 32bit
> DOS kernel (which if I recall correctly has been done a couple of times),

The "32-bit DOS kernels" have always been meant to run 16-bit programs. Only the system internals are 32-bit. This is, guess what, similar with what I am trying to do with x86-64 UEFI.

(If a "32-bit DOS kernel" cannot run existing programs, even on an Intel CPU, then there is not much reason for calling it DOS, except for marketing.)

> nor does it make very much sense to make a 64bit Linux kernel.

If you compare how system calls are described in Linux man pages (hint: the syscall(2) man page, and friends), and how system calls are described in Ralf Brown's Interrupt List, you will see the huge and obvious difference.

But of course if you see everything as just a huge sea of ones and zeros, then there is no difference.

Thank you!

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

Hello RayeR,

> OK, there is way to switch to RM and back but question is that UEFI runtime
> services are compatible with it and how many time it takes this overhead
> (saving context, etc) when switching back and forth too often. I guess that
> once you switch to RM and change some HW state then it will mess up UEFI
> when you switch back. I don't know if UEFI design was count with such
> option in it's architecture.

Actually it gets better (or worse?) than that --- UEFI distinguishes between "boot services" and "runtime services".

"Boot services" are, by right, only to be used by bootloaders, and boot managers that may load bootloaders. Before a bootloader starts up an actual system kernel, it is expected to "exit" the boot services --- free up the memory and resources used by them. After that the boot services are considered to be unavailable. Only the "runtime services" can be expected to be available to the kernel.

The fun part: most of the useful I/O drivers, including disk I/O and console I/O (!), are only available as boot services.

(Well, OK, the frame buffer for console I/O will still stick around even after boot services are exited:

> > [The UEFI Graphics Output Protocol] also provides an efficient BitBlitter
> > function, which you can't use from your OS unfortunately. GOP is an EFI
> > Boot Time Service, meaning you can't access it after you call
> > ExitBootServices(). However, the framebuffer provided by GOP persists, so
> > you can continue to use it for graphics output in your OS.

I have found this mighty useful for debugging.)

So basically the expectation is that the kernel will (re)do the initialization of the disk I/O and console I/O functionality, etc., based on the ACPI tables.

> BTW on MBs without CSM it is still a possibility to compile opensource
> SeaBIOS as CSM and do BIOS mod to insert it in. But I didn't read any
> success story about it yet.

I think, but I am not sure, that one needs to install the SeaBIOS as a sort of extension ROM inside the machine for this to work.

(The TianoCore sources seem to suggest (to me) that the UEFI firmware needs to detect the CSM very early in its initialization...)

> low level and sometimes undocumented stuff needed for real dos64. An it
> remembers me there already was/is RDOS
> project that is not much discussed anywhere - at least it contains
> some attempt to handle ACPI. But I was unable to boot it on my PC.

Thanks for the link! I think I have not come across RDOS before --- perhaps I should check it out.

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

Hello glennmcc,

> Nope... I mean an ACTUAL 32bit DOS kernel
> Don't know if this one is still under development or not but it was one of
> the attempts I had heard of a long time ago.
> https://board.flatassembler.net/topic.php?t=12396

I fail to see how this should be considered as a variant of "MS-DOS", and not as a separate operating system of its own (which is perfectly fine in itself).

It is like someone wrote a new OS which superficially looks and feels like Linux, but which does not even try to be able to run existing Linux programs.

Speaking of Linux, Linus himself wrote an entire MSc thesis about the whole idea of OS portability.

Thank you!

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

> Hello glennmcc,
>
> > Nope... I mean an ACTUAL 32bit DOS kernel
> > Don't know if this one is still under development or not but it was one
> of
> > the attempts I had heard of a long time ago.
> > https://board.flatassembler.net/topic.php?t=12396
>
> I fail to see how this should be considered as a variant of "MS-DOS", and
> not as a separate operating system of its own (which is perfectly fine in
> itself).
>
> It is like someone wrote a new OS which superficially looks and feels like
> Linux, but which does not even try to be able to run existing Linux
> programs.
>
> Speaking of Linux, Linus himself wrote an entire
> MSc
> thesis about the whole idea of OS portability.
>
> Thank you!

_I_ never made any mention of that crap OS
which _you_ have now introduced into the thread.

Also never said anything about a 32bit nor 64bit DOS which could
run existing 16bit or 32bit DOS programs.

When Linus built 32bit Linux... were there any existing 32bit Linux programs ?

When he advanced it to 64bit... were there any existing 64bit Linux programs ?

Be all of that as it may... the only thing I originally asked was...

Q: Has anyone ever even attempted to create an actual 64bit DOS kernel ?

And of-course the answer is... "No".
(or at-least not that we know of)

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

Hello glennmcc,

> Also never said anything about a 32bit nor 64bit DOS which could
> run existing 16bit or 32bit DOS programs.

OK, so what exactly is the point of calling an OS "a 64-bit MS-DOS" when it cannot actually run any existing MS-DOS programs at any level whatsoever?

OK, suppose someone creates a 64-bit OS and calls it "a 64-bit MS-DOS". How does one make existing MS-DOS software (or the source code thereof) run on this new "64-bit MS-DOS"? How exactly will the porting process be different from porting some existing MS-DOS program to, say, Solaris? Or to Windows? What exactly is it that will make this new OS "a 64-bit MS-DOS", and Solaris or Windows "definitely not a 64-bit MS-DOS"?

The distinction you make between "a 64-bit MS-DOS" and "definitely not a 64-bit MS-DOS" sounds like a distinction without a difference. Words need to have some connection with reality in order to be meaningful.

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

> Hello glennmcc,
>
> > Also never said anything about a 32bit nor 64bit DOS which could
> > run existing 16bit or 32bit DOS programs.
>
> OK, so what exactly is the point of calling an OS "a 64-bit MS-DOS" when it
> cannot actually run any existing MS-DOS programs at any level
> whatsoever?
>
> OK, suppose someone creates a 64-bit OS and calls it "a 64-bit MS-DOS".
> How does one make existing MS-DOS software (or the source code thereof) run
> on this new "64-bit MS-DOS"? How exactly will the porting process be
> different from porting some existing MS-DOS program to, say, Solaris? Or
> to Windows? What exactly is it that will make this new OS "a 64-bit
> MS-DOS", and Solaris or Windows "definitely not a 64-bit MS-DOS"?
>
> The distinction you make between "a 64-bit MS-DOS" and "definitely not a
> 64-bit MS-DOS" sounds like a distinction without a difference. Words need
> to have some connection with reality in order to be meaningful.

_I_ never said ANYTHING about MS.

What _I_ asked and have continued to discuss is.. a 64bit DOS

I also have never suggested that a 64bit DOS should be able to run existing 16bit or 32bit programs.

Again, all I asked was....

Q: Has anyone ever even attempted to create an actual 64bit DOS kernel ?

Why did your brain automatically convert "DOS" into "MS-DOS" ???

Why not "DOS" into "DR-DOS" ?

Why not "DOS into "FreeDOS" ?

Why did it make any conversion whatsoever ?

Since so many millions upon millions seem to be unable to make the
distinction between DOS & MS-DOS...
the Micro$hit brainwashing seems to have been a complete success.

I my case... when I speak of booting my computers to DOS,
the DOS I am booting to since 1997 is OpenDOS v7.01

Before that it was DR-DOS v6.0 and before that DR-DOS v5.0

Every machine I have ever owned which came with MS-DOS already on it,
had it removed to be replaced by one of the above within just a few
minutes of being in my possession.

Had I known that asking one simple question could cause this much
controversy... I would not have asked it.

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

> _I_ never said ANYTHING about MS.

See below.

> What _I_ asked and have continued to discuss is.. a 64bit DOS
>
> I also have never suggested that a 64bit DOS should be able to run existing
> 16bit or 32bit programs.

Okay. Then take an x64 Linux distro or Windows x64 and be happy. Both work on/with disks, so these qualifies as "DOS".

> Again, all I asked was....
>
> Q: Has anyone ever even attempted to create an actual 64bit DOS kernel ?
>
> Why did your brain automatically convert "DOS" into "MS-DOS" ???
>
> Why not "DOS" into "DR-DOS" ?
>
> Why not "DOS into "FreeDOS" ?

In general, FreeDOS, DR-DOS, PTS-DOS, ..., were modelled after MS-DOS. Not talking about MS-DOS in this case, would be not talking about DOS anymore as we understand it in this forum.

Do you want to talk about putting an ARM64 CPU to a C64 and creating a 64-bit Commodore DOS now?

> I my case... when I speak of booting my computers to DOS,
> the DOS I am booting to since 1997 is OpenDOS v7.01
>
> Before that it was DR-DOS v6.0 and before that DR-DOS v5.0
>
> Every machine I have ever owned which came with MS-DOS already on it,
> had it removed to be replaced by one of the above within just a few
> minutes of being in my possession.

Nice. But as you see, your case is not everybody else' case.

> Had I known that asking one simple question could cause this much
> controversy... I would not have asked it.

Not the first time in human history, that "simple" questions are not so simple to answer.

---
Forum admin

> The fun part: most of the useful I/O drivers, including disk I/O and
> console I/O (!), are only available as boot services.

Aha, I didn't know this. I would see a good point that DOS32/64 could use this services. Isn't there really some option or boot process that would leave the services available? - don't call the ExitBootServices()? What if you make DOS32/64 as UEFI application, similar to UEFI shell? BTW did someone tried to compile come simple UEFI app? It's some kind of PE file. I don't know what comilers support this target, you probably would need Tianocore src for headers & libs, and if is there some binary compatability - ABI to run one app across verious verisons of UEFI systems...

> I think, but I am not sure, that one needs to install the SeaBIOS as
> a sort of extension ROM inside the machine for this to work.

Yes, SeaBIOS can exist in form of an extension ROM. It could be legacy ROM or UEFI ROM and it's not dependent on Coreboot. I don't know deails bout CSM how it's really represented. I belive there are some UEFI FW manipulation tools that let you insert/remove CSM or other modules. I don't have setup any UEFI machine for just playing, my current PC has the latest non-UEFI Award BIOS.

> Thanks for the link! I think I have not come across RDOS before ---
> perhaps I should check it out.

Go and try it. It compiles fine with OpenWatcom but then freeze at boot even when I compiled minimal safe as possible configuration.

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

As I already posted here, have look at RDOS http://www.rdos.net/eng/
This seems to be most recent and advanced 32b DOS, check SVN http://www.rdos.net/svn/trunk/
AFAIK the last update that I checked was in 2019 or 2020

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

> Do you want to talk about putting an ARM64 CPU to a C64 and creating a
> 64-bit Commodore DOS now?
>

That would be a great idea.

Can you imagine how great it would be to then recompile
all of those old C64 games as 64bit ???

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

Hello glennmcc,

> Can you imagine how great it would be to then recompile
> all of those old C64 games as 64bit ???

Well, for me, I am not in the business of "imagining". I write code; and maybe I try to plan how I write code.

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

> Well, I have been trying
> to get something going that can boot from an x86-64 UEFI environment and,
> maybe at some point, usefully run 16-bit code.

OK, I have made a tiny bit of progress in getting legacy code to run natively on x86-64 UEFI.

My bootloader can (sort of) now run an unmodified kernel from MIT's Xv6 teaching operating system, which originally had to be started from a legacy BIOS.

There is still much more to be done, of course.

Thank you!

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

By the way: the author of Cosmopolitan recently spun off one of its subprojects into its own Git repository: https://github.com/jart/blink . This is an x86-64 virtual machine, similar to QEMU, but smaller.

Thank you!

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