FreeDOS and UEFI

[dasyar]

Not sure about asking here, but does anybody know how to make a bootable FreeDOS HD. This is a new system that has the UEFI bios with no legacy support. It seems that when you do a format C: /S, it does a format and a system transfer but the UEFI does not recognize it. Anybody figure out how to get around this?

Thanks

[caseih]

Sorry, it's not possible for UEFI to boot MS-DOS, at least directly. There might be a BIOS emulator that can be installed into UEFI but I suspect there would be problems as UEFI boots directly into 32 or 64-bit protected mode, whereas MS-DOS requires 16-bit real mode. In fact FreeDOS's web page confirms that it's not possible to boot it under any EFI system: http://wiki.freedos.org/wiki/index.php/UEFI

EDIT: it's more than just a real-mode BIOS thing. There's also the issue of hard drive partition table compatibility.

In short, the only way to run MS-DOS (or FreeDOS or anything similar) is in an emulator, like DosBox. Even Windows itself lacks the ability to run vm86 virtual machines that MS-DOS would require.

[marcov]

Afaik most PC UEFI's still have a "legacy bios".

That should be easily testable with a freedos live cd, or even an older Linux or windows CD.

Since also these 32-bit OSes had 16-bit first stage loaders.

[caseih]

True. Legacy boot support has to be enabled in the EFI settings screen. My understanding is that enabling Legacy Boot will turn off UEFI completely, and will make any already installed OS unbootable until you return to EFI mode.

Legacy boot support will disappear in 2020.

[badidea]

'They' don't seem eager to build UEFI support:
http://wiki.freedos.org/wiki/index.php/ ... or_UEFI.3F

[fatman2021]

Not sure about asking here, but does anybody know how to make a bootable FreeDOS HD. This is a new system that has the UEFI bios with no legacy support. It seems that when you do a format C: /S, it does a format and a system transfer but the UEFI does not recognize it. Anybody figure out how to get around this?

Thanks

Use VirtualBox...

[marcov]

True. Legacy boot support has to be enabled in the EFI settings screen. My understanding is that enabling Legacy Boot will turn off UEFI completely, and will make any already installed OS unbootable until you return to EFI mode.

Legacy boot support will disappear in 2020.

Linux installers work fine, despite not enabling legacy boot, and the same DVDs boot on old Pentium D's that guaranteedly don't have an UEFI.

It is only the so called "secure" boot that might be incompatible, but that is incompatible with booting anything else. Only big OEM hardware enable it by default anyway, so I would take that 2020 date with a pinch of salt. Outside of the corporate world, secure boot is a dead horse.

[caseih]

I think the DVDs have some kind of dual boot functionality that boots 16-bit grub if you're using legacy boot, or the 32-bit EFI grub if you're using EFI.

As for FreeDOS or MS-DOS, without enabling Legacy Boot, EFI will not boot MS-DOS from an MS-DOS partition. Nor would it even run without the BIOS resident in memory.

We can all wish that EFI's secure boot doesn't matter outside of corporate computers, but we'd be mistaken. If using EFI at all, Windows 10 *requires* secure boot be enabled. Future versions of Windows will not support legacy boot at all (or BIOS computers), once legacy boot disappears from PCs sometime around 2020. MS is driving this. Secure boot is enabled by default on all shipping systems right now, because Windows requires it. Linux distros work with secure boot by having MS sign the Linux distro's keys. Also users can add their own keys to the secure boot key store if they make a custom kernel. If you don't need to run windows at all, it's easy to disable secure boot. But not all machines (especially some laptops) even allow disabling secure boot.

[marcov]

We can all wish that EFI's secure boot doesn't matter outside of corporate computers, but we'd be mistaken. If using EFI at all, Windows 10 *requires* secure boot be enabled.

(it could be with cdroms. It seems improbable, and most bioses seem to lack the legacy bios option, leading me to believe is simply default enabled with some fallback/forward mechanism, e.g. partition table type detection)

This is afaik not true. If you choose GPT partitioning for a blank disk in windows, the whole shebang will go in EFI mode. No secure boot in sight. Motherboards also don't enable it by default. (of that I'm sure)

True, big OEMs have this in their licensing. But actually in early windows 8 times I had the feeling they were much more aggressive than now. It seems they ran out of steam/momentum.

Future versions of Windows will not support legacy boot at all (or BIOS computers), once legacy boot disappears from PCs sometime around 2020. MS is driving this. Secure boot is enabled by default on all shipping systems right now, because Windows requires it.

How old is that information?

Some forms of Windows licensing require it. Technically secure boot is afaik just verifying signatures on EFI partition boot loaders, and is separate from EFI (and GPT) itself.

Linux distros work with secure boot by having MS sign the Linux distro's keys. Also users can add their own keys to the secure boot key store if they make a custom kernel. If you don't need to run windows at all, it's easy to disable secure boot. But not all machines (especially some laptops) even allow disabling secure boot.

Indeed, many laptop forms that are hybrids between tablet and OS don't. I assume that also gets a licensing discount.

I haven't gotten any big brand laptops lately myself (my most current one is Medion, which had the option and the one before was a win8.1 Sony Vaio which had the option, but entering the bios was complicated)

Are you really sure this is actual situation, and not Win8 era policy that is not entirely discounted, but not really actively pursued/pushed anymore?

[caseih]

Yes you're right. My information is a bit dated, back a couple of years when people were trying to dual boot Linux and Windows 10. It appears Windows 10 (at least some variants like Home or Pro) does allow you to boot it with secure boot disabled. Apparently if you are using some legacy drivers, you must disable secure boot. Interesting to learn this.

But secure boot is definitely still pushed by default and on by default on any computer I've ever seen. According to several articles from a year or so ago (and i haven't seen anything contradicting this), if a manufacturer wants to put a windows sticker on their computer (and they all do since they bundle Windows), MS requires them to enable secure boot by default, and presumably use this to secure the OEM windows install[1]. MS does not actually dictate to vendors whether they must provide a way to disable secure boot, so that door is always open (or closed, depending on how you look at it).

I have confirmed that for DVDs, there is some kind of hybrid boot process. Linux Mint's install doc says, "The Linux Mint ISO can be booted both in EFI or BIOS mode. In EFI mode it shows a grub menu. In BIOS mode it shows an isolinux menu." Isolinux is a 16-bit real-mode boot loader that has been used to boot Linux on CD-ROMs and DVDs for many years, much like grub (and lilo before it) was used on hard drives. Of course with isolinux or the old grub, the bootloader requires the BIOS to be present to load the first bits from the drive, but once the kernel is loaded and executed, the CPU is switched to protected mode and the BIOS is no longer accessible or used. I wonder if modern CPUs still start in real mode and have to be bootstrapped into protected mode by the EFI system.

[1] According to https://www.howtogeek.com/116569/htg-ex ... for-linux/, dated 2017.

[marcov]

But secure boot is definitely still pushed by default and on by default on any computer I've ever seen. According to several articles from a year or so ago (and i haven't seen anything contradicting this), if a manufacturer wants to put a windows sticker on their computer (and they all do since they bundle Windows), MS requires them to enable secure boot by default, and presumably use this to secure the OEM windows install[1]. MS does not actually dictate to vendors whether they must provide a way to disable secure boot, so that door is always open (or closed, depending on how you look at it).

True, but that is the easy part, vendors also like to enable it, since they get a "can't tamper" feeling from it, market it as secure (realistic or not, never proven how "secure" it really is, when was the last bootsector virus/worm?), and hope that will save in support in the long run.
(fun fact: afaik in the EU you can return bundled windows, and your vendor has to comply, I can only find an old wiki reference for it https://en.wikipedia.org/wiki/Bundling_ ... und_policy so it might not be too practical)

I assume as long as the EFI partition has been created and you only install major distros it doesn't matter much anyway.

But nobody likes trouble for nothing, and since the stock firmwares have a unlock feature, so rarely anyone dares to remove it.

So I think the 2020 date is MS wishful thinking from a time when 2020 was still a long time away, unless you saw it confirmed recently. Microsoft doesn't even talk about "future versions of windows" anymore, since we are stuck with a mutating win10 forever :-)

I have confirmed that for DVDs, there is some kind of hybrid boot process.

Interesting, thanks. The bit about the legacy bios only being activated during the initial boot also rings a bell. I've heard that before too. So even when there is a legacy bios, it might not be there post boot and not support more services than what bootloaders typically use.

I wonder if modern CPUs still start in real mode and have to be bootstrapped into protected mode by the EFI system.

About ten years ago, I saw a session on FOSDEM (part of the open source bios trail) about starting x86 processors, and that is a multi stage process governed by the bios, started by one of the I/O processors in the firmware.(a later stage it runs with the cache as memory while the memory system initializes the rest, but then at least it can execute x86 code).

But OEMs probably don't have the knowledge to customize this.

I think they simply switch to some mode (my guess is 32-bit since code is tighter(flash!) and tools and programming models are more familiar than 16-bit), and switch back if necessary.

BIOSes of expansion cards are afaik 32-bit too, so they can't stay in 16-bit mode from CPU boot to OS boot anyway.

[rugxulo]

The bit about the legacy bios only being activated during the initial boot also rings a bell. I've heard that before too. So even when there is a legacy bios, it might not be there post boot and not support more services than what bootloaders typically use.

About ten years ago, I saw a session on FOSDEM (part of the open source bios trail) about starting x86 processors, and that is a multi stage process governed by the bios, started by one of the I/O processors in the firmware.(a later stage it runs with the cache as memory while the memory system initializes the rest, but then at least it can execute x86 code).

I think they simply switch to some mode (my guess is 32-bit since code is tighter(flash!) and tools and programming models are more familiar than 16-bit), and switch back if necessary.

BIOSes of expansion cards are afaik 32-bit too, so they can't stay in 16-bit mode from CPU boot to OS boot anyway.

I think most BIOSes (since a while) use SMM (e.g. 586's "RSM" instruction, which more or less replaced LOADALL, if that tells you anything). But I'm no expert, so I don't know any of the details beyond that. (Presumably something like 32-bit unreal mode, compiled C.)

[angros47]

FreeDos is not supposed to work on a system that has no BIOS, and a port is not planned. DOS uses too many calls to BIOS INTs, and those INTs will be removed on a system that has no BIOS (the reason is that a BIOS INT calls to a 16 bit piece of code, that in 32 bit mode slows down the processor (vorcing it to switch to virtual 86 mode, perform the call, and switch back to 32 bit mode), and in 64 bit mode is just impossible. This is the reason why BIOS calls are not used any more in modern operating systems, and are obsolete.

In theory, all the calls to BIOS interrupts could be replaced by something else, but such a reworking would mean almost a total rewrite of FreeDOS kernel, not just a fix. Even worse, DOS in origin was such a barebone system that a lot of applications, instead of using its APIs (that were accessed through interrupts, just like a BIOS call), they directly used BIOS interrupts.
For example, to output a string of text on the screen, many softwares (gwbasic, for example) used INT 10h (an interrupt that calls a BIOS function), and not INT 21h (an interrupt provided by DOS). So, gwbasic would not work without BIOS, even if the operating system itself were able to boot. And since DOS is mostly used with legacy applications, if most of them were unable to work on a new motherboard DOS would be totally useless.

Basically, a DOS designed to work on a motherboard with no BIOS would need to provide an underlying kernel to handle the hardware (disk, video output, and so on), and a software to emulate the bios calls. It's surely doable, but it would basically be the same of running DosBox or DosEmu on a minimalistic Linux kernel

[rugxulo]

FreeDos is not supposed to work on a system that has no BIOS, and a port is not planned. DOS uses too many calls to BIOS INTs, and those INTs will be removed on a system that has no BIOS (the reason is that a BIOS INT calls to a 16 bit piece of code, that in 32 bit mode slows down the processor (vorcing it to switch to virtual 86 mode, perform the call, and switch back to 32 bit mode), and in 64 bit mode is just impossible. This is the reason why BIOS calls are not used any more in modern operating systems, and are obsolete.

Switching to V86 mode from 32-bit pmode is not slow at all. That was by design.

64-bit is not impossible. With newer VT-X, you can do many things.

BIOS may be obsolete as in modern OSes don't need it anymore, but its death is probably more due to lack of availability, difficulty, or maintenance cost problem rather than just "we don't like it anymore".

In theory, all the calls to BIOS interrupts could be replaced by something else, but such a reworking would mean almost a total rewrite of FreeDOS kernel, not just a fix.

Which is not that big, so it's not that hard (for someone of sufficient skill). Anybody who can write or maintain a BIOS can easily port FreeDOS to UEFI. (No, not me, obviously.)

Even worse, DOS in origin was such a barebone system that a lot of applications, instead of using its APIs (that were accessed through interrupts, just like a BIOS call), they directly used BIOS interrupts.
For example, to output a string of text on the screen, many softwares (gwbasic, for example) used INT 10h (an interrupt that calls a BIOS function), and not INT 21h (an interrupt provided by DOS). So, gwbasic would not work without BIOS, even if the operating system itself were able to boot. And since DOS is mostly used with legacy applications, if most of them were unable to work on a new motherboard DOS would be totally useless.

Hence why you'd probably focus "first" on all the FOSS applications that can (easily?) be rebuilt with free/libre tools (compilers, etc.) before worrying about tons of closed source stuff that did "undocumented" or difficult things.

Basically, a DOS designed to work on a motherboard with no BIOS would need to provide an underlying kernel to handle the hardware (disk, video output, and so on), and a software to emulate the bios calls. It's surely doable, but it would basically be the same of running DosBox or DosEmu on a minimalistic Linux kernel

Yes, and I believe DOSEMU is no minor miracle, giving how much difficulty it had to jump through just to work at all.

DOSBox is much different (but also good) and simpler since it is "portable" and does no low-level kernel-ring stuff. It doesn't even use a real DOS, only its fake one, and is only targeted towards old games. It's much less ambitious (but still highly successful).

You could also just use QEMU/KVM or VirtualBox and call that multitasking, but that's just a full virtual machine (preferably using VT-X). Still works fairly well, all things considered!

[angros47]

Switching to V86 mode from 32-bit pmode is not slow at all. That was by design.

64-bit is not impossible. With newer VT-X, you can do many things.

"Not impossible" doesn't mean "usable in everyday situations". There are plenty of "not impossible" tricks that have been actually used only in demoscenes

BIOS may be obsolete as in modern OSes don't need it anymore, but its death is probably more due to lack of availability, difficulty, or maintenance cost problem rather than just "we don't like it anymore".

BIOS is not just obsolete, it is deprecated. Actually, most of it features were replaced in the early '90s, for example, Windows 3.11 was able to bypass BIOS routines to access hard drives, using 32 bit drivers instead, and Linux used BIOS functions only as fallback solution ef everything else failed. Windows 95 could use the BIOS to access hardware, but that was discouraged, and an error message with a warning appeared if that happened.

Basically, from 1995 to 2001, BIOS was just a fallback, to be used when everything else failed. After that, it was used only to load the operating system. And with EFI, that has been introduced more or less in 2005, and went mainstream between 2010 and 2015, even that last thing was possible without BIOS. The only reason BIOS was left was retrocompatibility. It was obviously only matter of time before it was removed, and keeping a deprecated feature for 5 years was actually enough, I think.

Remember, in 2020 they won't "remove" BIOS from anything, they will just start selling motherboards that feature no BIOS (so, before current computers with BIOS will be replaced, likely 10 more years will pass)

Which is not that big, so it's not that hard (for someone of sufficient skill). Anybody who can write or maintain a BIOS can easily port FreeDOS to UEFI. (No, not me, obviously.)

Yes, they can, but why would anyone want to do that? Since the resulting OS would still be unable to run most DOS application? Anyone with the skills, the time and the goodwill to do that would likely prefer to develop their own OS instead of porting a non-functional DOS

Hence why you'd probably focus "first" on all the FOSS applications that can (easily?) be rebuilt with free/libre tools (compilers, etc.) before worrying about tons of closed source stuff that did "undocumented" or difficult things.

All the FOSS applications for DOS have already been ported to other operating systems, so there is no need for a DOS that can run only them. If they are all you need, you can go with a lightweight Linux distro, with OpenBSD, FreeBSD, or any other open source OS.

If you have to rebuild all the applications, to use them with the new operating system, you could as well switch to a totally different operating system, that already provides some native applications.