Index
> DOS > Theory: booting DOS on an UEFI-only system |
| Author |
|
|
revolution 04 Sep 2016, 08:00
In theory, yes.
|
|||
04 Sep 2016, 08:00 |
|
|
MrFox 04 Sep 2016, 08:23
Yes, it is possible but I'm afraid, intercepring interrupt vectors alone still won't give you a fully dos-compatible environment (I don't think there still are Video Memory buffers in the 'right' places, other non-interrupt related stuff...). I think those were actively used by DOS-games and other programs...
That's all apart from those hundreds of bios/dos vectors with all their functions you have to hook to get something tangible and usable. (Anyways, I'd be happy if there were a UEFI FASM programming environment - a FASM+IDE thing that would allow me to write code, compile it and test it on real hardware right away without having to reboot or use various virtual machines)... |
|||
|
04 Sep 2016, 08:23 |
|
|
Tomasz Grysztar 04 Sep 2016, 16:39
MrFox wrote: (Anyways, I'd be happy if there were a UEFI FASM programming environment - a FASM+IDE thing that would allow me to write code, compile it and test it on real hardware right away without having to reboot or use various virtual machines)... Porting flat editor in order to make an IDE is a harder task, because you need to write the entire UI (note how fasmw and fasmd, both using the same flat editor core, have completely different UI code). And porting fasmg (which is also being used for UEFI programming already*) is quite similar to porting fasm 1 - but it additionally requires malloc/realloc family of functions. If an environment lacks them, some third-party implementation may be needed. I think I may one day work on an realloc implementation for fasmg that could be used when porting to any OS that does not have such functions available. ___ * I also know of EBC (EFI Byte Code) assembly implementation for fasmg being actively developed, though in early stages. |
|||
|
04 Sep 2016, 16:39 |
|
|
rugxulo 09 Sep 2016, 01:20
Tomasz Grysztar wrote:
A very naive suggestion ... do these help? http://www.delorie.com/djgpp/malloc/ |
|||
|
09 Sep 2016, 01:20 |
|
|
Tomasz Grysztar 14 Sep 2016, 13:17
rugxulo wrote: A very naive suggestion ... do these help? Actually, fasmg could use a specialized malloc API that would allow to pass the hint that the block will never be resized or freed before the end of assembly, because fasmg has a lot of such allocations, and also a lot of ones that are very likely to get resized. |
|||
|
14 Sep 2016, 13:17 |
|
|
Trinitek 30 Oct 2016, 02:50
I've given it a good bit of thought up to this point, and I've come to the conclusion that the only way to implement this functionality effectively would be to implement it as a virtual machine.
Alternatively, I could implement it as a simulator, but I feel that would defeat the purpose of the project as a programming exercise because I could choose to simply port QEMU, Bochs, DOSBox, etc. as an EFI executable. |
|||
|
30 Oct 2016, 02:50 |
|
|
sleepsleep 30 Oct 2016, 05:07
https://blogs.intel.com/evangelists/2015/07/22/why-cheap-systems-run-32-bit-uefi-on-x64-systems/
Quote: the OS and firmware architecture need to match. if using uefi 32 bit, 32-bit DOS if using uefi 64 bit, 64-bit DOS? |
|||
|
30 Oct 2016, 05:07 |
|
|
revolution 30 Oct 2016, 05:29
sleepsleep wrote: if using uefi 32 bit, 32-bit DOS Just rewrite DOS from scratch to use UEFI. Should be easy, why hasn't someone done it yet?  |
|||
|
30 Oct 2016, 05:29 |
|
|
Trinitek 30 Oct 2016, 06:45
sleepsleep wrote: if using uefi 32 bit, 32-bit DOS Actually, what would prevent my bootloader from exiting 32-bit UEFI boot services and stepping up to long mode by itself if it's available? |
|||
|
30 Oct 2016, 06:45 |
|
|
revolution 30 Oct 2016, 08:59
Trinitek wrote: Actually, what would prevent my bootloader from exiting 32-bit UEFI boot services and stepping up to long mode by itself if it's available? |
|||
|
30 Oct 2016, 08:59 |
|
|
Trinitek 30 Oct 2016, 09:51
revolution wrote: Nothing. But you won't be able to use the 32-bit EFI services in 64-bit mode. You'd have to access everything with your own code and drivers. After some more thought, I think I may opt to write only a 32-bit version of this VM since the guest systems I have in mind are going to be things like FreeDOS, and I'm not aware of any 64-bit DOS extenders. (64-bit UEFI can boot 32-bit EFI execs right? I remember testing at one point but I don't recall that specifically.) For future reference, I'll include this link. https://technet.microsoft.com/en-us/library/dn387089.aspx If I want this to work, I need to copy what the popular kids are doing. My dance with VirtualBox's incomplete UEFI implementation bit me the last time I played with it. |
|||
|
30 Oct 2016, 09:51 |
|
|
Tomasz Grysztar 27 Feb 2017, 11:41
rugxulo wrote: A very naive suggestion ... do these help? http://www.cs.northwestern.edu/~pdinda/icsclass/doc/dsa.pdf Very much a recommended read for anyone who would like to try writing a custom malloc implementation. |
|||
|
27 Feb 2017, 11:41 |
|
|
rugxulo 01 Mar 2017, 20:17
Tomasz Grysztar wrote: I have found a good article that summarizes many different methods, including some I didn't know: Quite a long doc (78 pages!!), and I'm no Comp. Sci. professional, so I only barely skimmed it. Not sure how directly useful it is, seems more friendly advice than any actual solution. Probably because there is no one obvious solution for all uses. Vo's vmalloc sounded promising, but a quick search didn't show anything totally obvious (non-commercial license? meh, but maybe that was only for an older version). There's another site that has some old summaries of various Linux implementations, too. FYI, Free Pascal has heaptrc for reporting exactly how getmem/freemem is being called. But even this paper admits that malloc is usually tied to either programming language or OS. So, while maybe possible, it's unlikely that anyone would truly go bare metal if they want to be hosted by any popular modern OS. For example:
My point is that you'll end up having to "tune" for various OS families and editions and versions, which is probably more trouble than it's worth (unless you're extremely diligent). Though I'm sure you already knew that. Not sure why I'm posting, it's far beyond me! Just a friendly ramble from a noob.  |
|||
|
01 Mar 2017, 20:17 |
|
< Last Thread | Next Thread > |
Forum Rules:
|