3 ms·

They mean the installation process was improved, particularly with regards to the MBR. GPT and UEFI is not supported. GPT: http://wiki.freedos.org/wiki/index.

They mean the installation process was improved, particularly with regards to the MBR. GPT and UEFI is not supported. GPT: http://wiki.freedos.org/wiki/index.php/(Free)DOS_development_wishlist http://wiki.freedos.org/wiki/index.php/(Free)DOS_development... UEFI: http://wiki.freedos.org/wiki/index.php/UEFI http://wiki.freedos.org/wiki/index.php/UEFI

ale42 5y ago
This is expected, given how hard it would be to DOS in a UEFI-based environment. Is anyone aware of a BIOS emulation layer (or an actual BIOS...) that can be loaded into UEFI to start BIOS-aware OS/programs?
- WesolyKubeczek 5y ago
  Do you mean CSM?
  - ale42 5y ago
    Something like that, but rather on the form of a .EFI executable (for example), to load it on UEFI firmwares that don't provide a CSM: there are many of them...
    - jaclaz 5y ago
      Yes, what would be needed would be a "reversed Clover", but, though there is some work in this space, I don't think that there is anything actually working (besides the much simpler int10h provider for EFI, needed for Windows 7 and 2008 on motherboards without CSM), here a few projects are listed: http://reboot.pro/index.php?showtopic=22488 http://reboot.pro/index.php?showtopic=22488 but, even if something will come out, it will likely need to be adapted/targeted to specific hardware, unless somehow it is possible to translate transparently UEFI functions to and from BIOS interrupts. I believe that bare-metal DOS is going to become extinct and be relegated inside emulators or virtual machines. In itself it would not be that bad if we had actually working/useful native EFI programs/shells, or grub (or grub4dos, now also in a grub4efi version) related ones but AFAIK - and for whatever reasons - these are very rare.
- fredoralive 5y ago
  As far as I know it would be hard to do it outside of the boot firmware's own compatibility options (which most systems currently have AFAIK, but is probably on the way out). Whilst the old BIOS starts external code in Real Mode, with UEFI it sets the CPU into the operating mode. This means with most systems you'll be in 64 bit / Long Mode, and you can't leave that once entered. You could have fun with hypervisors etc., but I guess we're thinking bare metal here?
  - leeter 5y ago
    You can absolutely leave long mode once entered; it's just annoying and silly. In fact one of the plausible options for running a DOS on UEFI would be downgrading the mode to 'unreal' mode. But you'd still have to put BIOS replacement code in memory to manage that part. However the better option IMO is to allow the DOS kernel to just virtualize the applications using the virtualization extensions on almost all modern CPUs. Then you could do something like adding an emu.ini file next to the exe/com that sets things like memory and emulated hardware settings. Furthermore virtual machine BIOS code already exists for things like qemu etc. so there is a place to start on that too.
    - zozbot234 5y ago
      > Then you could do something like adding an emu.ini file next to the exe/com that sets things like memory and emulated hardware settings. The standard DOS-extender feature for setting these modes is a Program Information File (.PIF extension).
      - leeter 5y ago
        Honestly I was thinking similar but not exactly the same. More something with a VT-d memory map/port map so that the DOS application could potentially directly interface with legacy hardware without interfering or making the PIF incompatible. This has applications particularly in factories where they still use ISA interface cards with tooling etc. At the same time it would allow setting things like EGA/CGA compatibility requirements. Could you do it in the PIF? Probably, but I'd rather not risk breaking compatibility if possible. It's an idea only and would require research anyway assuming I actually had the time and energy to implement.

ale42 5y ago

This is expected, given how hard it would be to DOS in a UEFI-based environment. Is anyone aware of a BIOS emulation layer (or an actual BIOS...) that can be loaded into UEFI to start BIOS-aware OS/programs?

WesolyKubeczek 5y ago
Do you mean CSM?
- ale42 5y ago
  Something like that, but rather on the form of a .EFI executable (for example), to load it on UEFI firmwares that don't provide a CSM: there are many of them...
  - jaclaz 5y ago
    Yes, what would be needed would be a "reversed Clover", but, though there is some work in this space, I don't think that there is anything actually working (besides the much simpler int10h provider for EFI, needed for Windows 7 and 2008 on motherboards without CSM), here a few projects are listed: http://reboot.pro/index.php?showtopic=22488 http://reboot.pro/index.php?showtopic=22488 but, even if something will come out, it will likely need to be adapted/targeted to specific hardware, unless somehow it is possible to translate transparently UEFI functions to and from BIOS interrupts. I believe that bare-metal DOS is going to become extinct and be relegated inside emulators or virtual machines. In itself it would not be that bad if we had actually working/useful native EFI programs/shells, or grub (or grub4dos, now also in a grub4efi version) related ones but AFAIK - and for whatever reasons - these are very rare.
fredoralive 5y ago
As far as I know it would be hard to do it outside of the boot firmware's own compatibility options (which most systems currently have AFAIK, but is probably on the way out). Whilst the old BIOS starts external code in Real Mode, with UEFI it sets the CPU into the operating mode. This means with most systems you'll be in 64 bit / Long Mode, and you can't leave that once entered. You could have fun with hypervisors etc., but I guess we're thinking bare metal here?
- leeter 5y ago
  You can absolutely leave long mode once entered; it's just annoying and silly. In fact one of the plausible options for running a DOS on UEFI would be downgrading the mode to 'unreal' mode. But you'd still have to put BIOS replacement code in memory to manage that part. However the better option IMO is to allow the DOS kernel to just virtualize the applications using the virtualization extensions on almost all modern CPUs. Then you could do something like adding an emu.ini file next to the exe/com that sets things like memory and emulated hardware settings. Furthermore virtual machine BIOS code already exists for things like qemu etc. so there is a place to start on that too.
  - zozbot234 5y ago
    > Then you could do something like adding an emu.ini file next to the exe/com that sets things like memory and emulated hardware settings. The standard DOS-extender feature for setting these modes is a Program Information File (.PIF extension).
    - leeter 5y ago
      Honestly I was thinking similar but not exactly the same. More something with a VT-d memory map/port map so that the DOS application could potentially directly interface with legacy hardware without interfering or making the PIF incompatible. This has applications particularly in factories where they still use ISA interface cards with tooling etc. At the same time it would allow setting things like EGA/CGA compatibility requirements. Could you do it in the PIF? Probably, but I'd rather not risk breaking compatibility if possible. It's an idea only and would require research anyway assuming I actually had the time and energy to implement.