Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

I made my own DOS implementation (Announce)

posted by samwdpckr, 01.02.2024, 19:09
(edited by samwdpckr on 01.02.2024, 19:27)

> UEFI doesn't mean that you have to handle all the HW by yourself. UEFI
> offers runtime services and drivers for accessing storage (HDD, USB),
> keyboard and framebuffer.
> https://wiki.osdev.org/Using_UEFI_Runtime_Services_in_your_Kernel
Those UEFI runtime services are listed in the OSDev article:


        Efi_Get_Time                    GetTime;
        Efi_Set_Time                    SetTime;
        Efi_Get_Wakeup_Time             GetWakeupTime;
        Efi_Set_Wakeup_Time             SetWakeupTime;
        Efi_Set_Virtual_Address_Map     SetVirtualAddressMap;
        Efi_Convert_Pointer             ConvertPointer;
        Efi_Get_Variable                GetVariable;
        Efi_Get_Next_Variable_Name      GetNextVariableName;
        Efi_Set_Variable                SetVariable;
        Efi_Get_Next_High_Mono_Count    GetNextHighMonotonicCount;
        Efi_Reset_System                ResetSystem;
        Efi_Update_Capsule              UpdateCapsule;
        Efi_Query_Capsule_Capabilities  QueryCapsuleCapabilities;
        Efi_Query_Variable_Info         QueryVariableInfo;


I don't see anything related to disk or console I/O.

> But problem is that UEFI starts in 64-bit long mode (old 32-bit UEFI are
> probably no longer developed and supported) that makes it problematic to
> cooperate with realmode DOS (not sure if possible do some 16-64b mode
> switches safely without destrying UEFI structures).
UEFI does not have a standardized memory map like BIOS does. UEFI has only a limited set of functions that do not alter the memory map - the only boot services that are guaranteed to NOT alter the memory map are ExitBootServices() and GetMemoryMap() (if I remember their names correctly). BIOS-based operating systems, on the other hand, assume that everything starting from memory address ~60:0 to the kilobyte count in address 40:13 is safe to be used by the kernel. If there happens to be UEFI code or UEFI structures in that memory area, it will create problems.

UEFI has been designed (probably on purpose) in such way that it is NOT possible to create a universal "BIOS shim" that would work with every operating system that uses BIOS. Of course it would be possible to create something that uses the virtual-86 mode of x86 processors and run the DOS operating system inside that, but it would then be extremely hard to implement an environment that could also run DOS extenders and other 32-bit DOS applications. Most likely it would also have problems with accessing many I/O ports and handling interrupts. And also that "shim" would need to support every piece of hardware separately.

On top of that, UEFI cannot boot anything if the boot disk does not have a GPT partitioning table. The bootable binary (usually the bootloader of the operating system) must be a PE-formatted file in a FAT32 filesystem - also known as the "EFI partition". Most operating systems aren't even compatible with GPT partitioning, which isn't even a good partitioning scheme to begin with.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 119 users online (0 registered, 119 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum