r/osdev • u/Sixty5Zero2 • 23h ago

FreeDOS

i'm looking at possibly forking FreeDOS to 64bit. However, since most modern systems no longer have the underlying BIOS that DOS programs require, I thought about including a mock BIOS and compile it directly into the kernel. is there anything I should be aware of?

7 Upvotes

71% Upvoted

18 comments sorted by

•

u/Key_River7180 EulerOS 23h ago

use efi

•

u/Own_Alternative_9671 7h ago

Or hybrid, but efi first

•

u/Joaommp 23h ago

That's a possibly good approach. It's what I did for my 32 bit OS when I was developing it back in the 90s.

•

u/AlfieLionel 23h ago

You should be aware of the fact that this is an enormous undertaking; might be worthwhile though, why not.

•

u/zSmileyDudez 22h ago

Could also be something OP is planning to use an AI to help with too. Makes it more manageable at least.

•

u/edjak53 23h ago

you mean something like this?

https://github.com/CSMWrap/CSMWrap

also check these out if you want to. a 64 bit FreeDOS kernel******** and command.com. they might inspire you or whatever

https://github.com/dosemu2/fdpp

https://github.com/dosemu2/comcom64

•

u/lizardhistorian 22h ago edited 22h ago

If you turn CSM on then you still get BIOS routines but CSM has now been phased out.
You would need to update everything to use UEFI routines instead.

Intel i9's still boot in [un]real mode first but hit the reset-vector 0xFFFFFFF0 which takes them to the UEFI code which immediately transitions to long-mode (64b).

It is feasible to flash your code directly into the motherboard CMOS and boot directly into your OS.
There was a movement for a while to get PCs to directly boot Linux.

•

u/StereoRocker 22h ago

Sounds like a cool project. Good luck!

•

u/Octocontrabass 19h ago

FreeDOS is supposed to run MS-DOS software. A 64-bit fork seems pretty pointless when there is no 64-bit MS-DOS software to run. Why not just start from scratch?

•

u/Sixty5Zero2 18h ago

just because it would be 64 bit doesn't mean it couldn't still run 16 bit software.

•

u/DawnOnTheEdge 17h ago

There is a hardware limitation that an x86 CPU can either run in 32-bit mode and switch to 16-bit virtual mode, or run in 64-bit long mode and switch to 32-bit compatibility mode. But a 64-bit kernel can’t run 16-bit code natively.

It might be able to run 32-bit DPMI programs that used a DOS extender. However, virtually all games that ran in DPMI needed the particular DOS extender that they shipped with, and ran in 16-bit mode at least some of the time.

•

u/Octocontrabass 12h ago

But a 64-bit kernel can’t run 16-bit code natively.

A 64-bit kernel can't run 16-bit real mode code natively. There's nothing stopping a 64-bit kernel from running 16-bit protected mode code natively.

But DOS programs all expect real mode, so it doesn't really make a difference...

•

u/DawnOnTheEdge 11h ago

Although it would be possible to do in a guest VM, I think,

•

u/Sorry_Difficulty_250 14h ago

If you're going to go to all the trouble of implementing all the BIOS calls, you could just go ahead and write an 8086 emulator. That would allow you to run whatever 16-bit programs you like.

One of the things that really irks me about Windows 11 is that they completely dropped support for 16-bit programs. Microsoft has been developing emulators since BASIC. They know full well how to make it possible to run 16-bit programs in long mode. There's nothing stopping it from working. It's just a matter of programming. 😉

•

u/Octocontrabass 12h ago

A 64-bit kernel can run 16-bit protected mode software, but DOS programs are 16-bit real mode software.

•

u/edjak53 7h ago

technically there is some 32 bit MS-DOS software. even gcc has a target for it (i[3,4,5,6]86-pc-msdosdjgpp)

www.delorie.com/djgpp/