flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > DOS > Theory: booting DOS on an UEFI-only system

Author
Thread Post new topic Reply to topic
Trinitek



Joined: 06 Nov 2011
Posts: 224
Theory: booting DOS on an UEFI-only system
I've given this some thought, but I want to bounce this idea off of you guys.

On systems that have no BIOS and only have UEFI, would it theoretically be possible to have a UEFI boot executable install a set of BIOS hooks that would, for example, emulate INT 0x10 graphics services through GOP?
Post 04 Sep 2016, 06:07
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14500
Location: WTC Building 7
In theory, yes.
Post 04 Sep 2016, 08:00
View user's profile Send private message Visit poster's website Reply with quote
MrFox



Joined: 17 Aug 2016
Posts: 52
Location: Russia
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)...
Post 04 Sep 2016, 08:23
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6194
Location: Kraków, Poland

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 fasm is quite easy because it was designed with this in mind (of course, as long as your target architecture can run 32-bit x86 code). The old guide to fasm's internals contains all the information you need to port fasm to another environment and most of it is up to date.

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.
Post 04 Sep 2016, 16:39
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2079
Location: Usono (aka, USA)

Tomasz Grysztar wrote:

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.



A very naive suggestion ... do these help?

http://www.delorie.com/djgpp/malloc/
Post 09 Sep 2016, 01:20
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6194
Location: Kraków, Poland

rugxulo wrote:
A very naive suggestion ... do these help?

http://www.delorie.com/djgpp/malloc/

I don't know how large the differences between various of these options would be in case of fasmg, but perhaps it would be worth it to take the all and test one by one by linking the libc version of fasmg with them.

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.
Post 14 Sep 2016, 13:17
View user's profile Send private message Visit poster's website Reply with quote
Trinitek



Joined: 06 Nov 2011
Posts: 224
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.
Post 30 Oct 2016, 02:50
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 6290
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699
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?
Post 30 Oct 2016, 05:07
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14500
Location: WTC Building 7

sleepsleep wrote:
if using uefi 32 bit, 32-bit DOS

if using uefi 64 bit, 64-bit DOS?

Hehe, yup. 32-bit DOS with no BIOS, makes perfect sense. And 64-bit DOS? Of course, why not.

Just rewrite DOS from scratch to use UEFI. Should be easy, why hasn't someone done it yet? Wink
Post 30 Oct 2016, 05:29
View user's profile Send private message Visit poster's website Reply with quote
Trinitek



Joined: 06 Nov 2011
Posts: 224

sleepsleep wrote:
if using uefi 32 bit, 32-bit DOS

if using uefi 64 bit, 64-bit DOS?

The 32- or 64-bit requirement would only apply to the virtualization layer that I'm proposing, not the operating system running under it. (Of course, the guest OS bit-ness limit would be the bit-ness of the host VM.)

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?
Post 30 Oct 2016, 06:45
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14500
Location: WTC Building 7

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?

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.
Post 30 Oct 2016, 08:59
View user's profile Send private message Visit poster's website Reply with quote
Trinitek



Joined: 06 Nov 2011
Posts: 224

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.

I'd assume that stepping down to 32-bit mode to call services would be an option? Even though I don't intend on relying on the runtime services.

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. Wink My dance with VirtualBox's incomplete UEFI implementation bit me the last time I played with it.
Post 30 Oct 2016, 09:51
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6194
Location: Kraków, Poland

rugxulo wrote:
A very naive suggestion ... do these help?

http://www.delorie.com/djgpp/malloc/

I have found a good article that summarizes many different methods, including some I didn't know:
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.
Post 27 Feb 2017, 11:41
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2079
Location: Usono (aka, USA)

Tomasz Grysztar wrote:
I have found a good article that summarizes many different methods, including some I didn't know:
...
Very much a recommended read for anyone who would like to try writing a custom malloc implementation.



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:


  • Linux 3.14 (circa 2014) has zram.
  • Windows 8 (circa 2012) has various memory improvements.
  • Even DJGPP's FAQ (see Footnote #26) claims that DPMI 0.9 is more limited because "since the stack must be contiguous and expands downwards, growing it during program's run would require a very complicated code, unless it is pre-allocated at startup".


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. Confused
Post 01 Mar 2017, 20:17
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.