VBE higher resolution text modes support?

[rdos]

Not sure why bzt keeps insisting you can't do it

Erm, where did I said that, exactly? Never said you can't do it, I do it like that too. Setting up paging is a lot more difficult than having to do nothing. Your argument that it's "no more difficult" does not stand with VMM either. (And before you ask, yes, setting up paging for long mode is a lot more difficult with UEFI than with BIOS, because with BIOS you can use whatever mapping you want, while with UEFI you must make sure of that the dynamically allocated areas are mapped properly in your new paging table, otherwise your loader will crash.)

You are completely wrong here on almost every account here. It is not hard to mount a hard drive or partition.

Explain, how am I wrong here? Mounting IS needed, file system driver is needed, and it ain't portable, and it is pretty hard if your OS does not support it natively. But my toolchain for example doesn't rely on the OS mount at all, I generate the disk image programmatically for portability reasons, so yes, I know exactly what I'm talking about. (Fact: my image creator works on MacOS, Windows, Linux and BSDs as well. Does your Makefile too?)

Cheers,
bzt

I see no real difference in this area. It's a lot easier to load your OS image from the file system with UEFI than with BIOS. You can just let UEFI do it with some simple calls, while with BIOS you need to parse the file system in the boot loader itself to find the OS image.

I have tools to create both GPT and MBR partition schemes in the OS itself, and the complexity is not much different. The GPT solution is probably even simpler since I don't need to add specific boot sectors, rather I only need to put the efi-boot files and the OS image on the EFI system partition, which actually is a standard FAT32 partition.

My problem is more with building the efi boot file itself. It requires a Unix-like environment (I typically use cygwin). Since there are both 32-bit and 64-bit versions, I need to install both 32-bit and 64-bit cygwin. OTOH, I only build them once and then check the binaries into my SVN so it doesn't need to be part of the general build process.

[sham1]

Please indulge me while I contribute to this (slightly) off-topic discussion, since the original question seems to have been handled rather conclusively.

Like I said, reinventing the wheel. Whatever floats your boat.

This is a rather odd critique/point to bring up when talking about hobbyist OS development. This is considering the fact that osdev by its nature has always been about "reinventing the wheel" so to say, whether it's for the purposes of study, recreation and so on. You say "use standard tools" but isn't that also an argument against doing OS development in the first place? Why develop a kernel, just use Linux. Why write an user space, just use busybox or GNU Coreutils. Why make your OS unique, just do POSIX (not to say that POSIX OSes can't be nor aren't unique, but you know). And so on, and so forth.

Complexity of standards is a valid criticism, and UEFI is no exception. It should be thought in terms of its tradeoffs though. It is true that UEFI gives a lot nice abilities and APIs, but it's also a valid complaint to say that getting the entry points for said APIs may be a bit convoluted, or that the usage of wide char strings for no apparent reason is silly.

Its also a correct point to say that UEFI is large and in some ways complex. Some might call that "bloated and overly complicated" while others might think of it as being a rich API for solving a complicated problem and that the complexity of the APIs and such only reflect the complexity that arises from contemporary computers, a lot of which just wasn't a thing back when the original IBM PC came out, for example.

There really is no correct answer.

[bzt]

I see no real difference in this area. It's a lot easier to load your OS image from the file system with UEFI than with BIOS.

Only if you want to use FAT. For all the other filesystems (ext2 for example) it is a lot more complicated.

You can just let UEFI do it with some simple calls, while with BIOS you need to parse the file system in the boot loader itself to find the OS image.

True, but parsing FAT to load a file is very simple, fits into 512 bytes easily (take a look at MS-DOS VBR or BootProg or Bootf for example). Considering all the other additional complexity, I don't think it's a good trade... (Don't get me wrong, the idea that there's a firmware interface to load directly files from a partition is good, it is the actual implementation I have issues with. Your code using this "simple call" will be compiled unavoidably bigger than the BIOS counterpart, and it now has an additional dependency. It's not the sector read that you have to worry about, but also you can't know for sure if UEFI detects the file system correctly and able to load your file. I had issues with 12/16/32, so I had to waste disk space (several megabytes, about 10 times more than the actual useful data!) just to guarantee minimal number of clusters. This is completely a non-issue with BIOS boot sectors, where you always choose the appropriate code for the fs.)

I have tools to create both GPT and MBR partition schemes in the OS itself, and the complexity is not much different. The GPT solution is probably even simpler since I don't need to add specific boot sectors, rather I only need to put the efi-boot files and the OS image on the EFI system partition, which actually is a standard FAT32 partition.

Well, you must write the boot sector anyway (if nothing else for the partition table with 0xEF and the 0xAA55 magic), and manipulating FAT table is an additional complexity (admitted, not that hard, I solved it in about 200 SLoC). My biggest issue with GPT is that it's full of unused and unnecessary data (seriously, has anyone ever used partition UNICODE16 names instead of drives, well, ever?) and you have to repeat it at the end of the disk, which means you must know the size of the resulting image in advance, or you must keep the entire thing in memory, or you must write in chunks using seeks. Not to mention the minimum size requirements for alignments and FAT32 cluster numbers, and the inconsistencies in the spec that leads to incompatible partitioning tools (seriously, no boot this partition flag? How come?).

These aren't big things, but it adds up, little by little up to the point where a beginner can't create a disk image on its own (not everybody is as experienced as you and me, for us creating GPT and FAT tools is a piece of cake, but that's not common). Now on top of all of that add Secure Boot to the mix, and a hobby OS developer is completely screwed.

My problem is more with building the efi boot file itself. It requires a Unix-like environment (I typically use cygwin). Since there are both 32-bit and 64-bit versions, I need to install both 32-bit and 64-bit cygwin. OTOH, I only build them once and then check the binaries into my SVN so it doesn't need to be part of the general build process.

I've never heard of that (UEFI requiring a Unix-like environment), but yeah, creating an efi file is a lot more problematic too, as I've said the interface (which implies MS-ABI capable compiler and PE output) is definitely adds considerable complexity to your toolchain.

since the original question seems to have been handled rather conclusively.

You're absolutely right. We went quite off-topic, I'm sorry.

Cheers,
bzt

[kzinti]

This is a rather odd critique/point to bring up when talking about hobbyist OS development.

That's a fair critique. I do agree with you. Where I don't agree is when I see people saying that UEFI is very complicated and unmanageable when they are doing everything they can to use it the wrong way.

Comparing the work required to copy a 512 bytes stage-0 bootloader to the first sector of a disk with generating a full valid disk image with GPT and FAT partitions is digingenuous: you aren't comparing apples to apples.

If you want to create your disk images using your own tools, more power to you (like I said), but this choice has nothing to do with UEFI. Doing the same work for your BIOS-based OS will be the same amount of work. It has nothing to do with UEFI. So you can't use that as an argument to say that UEFI is complex and bloated. It's unrelated.

Is the barrier to entry higher? Maybe... Probably... But it's not orders of magnitudes more complex. That's is just FUD.

Its also a correct point to say that UEFI is large and in some ways complex. Some might call that "bloated and overly complicated" while others might think of it as being a rich API for solving a complicated problem and that the complexity of the APIs and such only reflect the complexity that arises from contemporary computers, a lot of which just wasn't a thing back when the original IBM PC came out, for example.

And the BIOS is not large and complex? It's a complete mess. And it is full of bugs just like UEFI is. The thing is you only need a small subset of it to get your OS going and that part is well known / well tested and the pitfalls are known. Well guess what, it is the same with UEFI. Stick to the main path and load your OS like Windows and Linux does and you won't run into many problems, if any.

There really is no correct answer.

I've built both a BIOS and a UEFI bootloaders. The amount of complexity and time I spend on each one is about the same. The amount of code I have in the end result is also about the same for each one. I am not a fan of the UEFI APIs... But when it comes to how much work was required and how much complexity/difficulty was involved with each, they are about the same.

But if you are willing to spend time to build your own tools to build your own images, that's great and I encourage anyone to do so. But don't come back saying UEFI is bloated and complex, it has nothing to do with your decision.