64-bit PE Bootloader

[CrypticRasta]

Does anyone know a 64-bit PE compliant bootloader that I could use for my project.

I know, I know, PE isn't a great choice to begin with but it is necessary under my circumstances.

[Octocontrabass]

Does anyone know a 64-bit PE compliant bootloader that I could use for my project.

UEFI.

Oh, that doesn't count? Okay, try BOOTBOOT.

it is necessary under my circumstances.

If you don't mind me asking, what circumstances?

[zaval]

Does anyone know a 64-bit PE compliant bootloader that I could use for my project.

freeldr of ReactOS.

But I think, one needs to develop his/her own OS Loader.

I know, I know, PE isn't a great choice to begin with but it is necessary under my circumstances.

I am amused at such excuses people feel the need to do. why? were you bullied by some aggressive gnu/dudes, that told you everything from MS is evil and now you are afraid to ask without making such lame excuses. IMHO, PE is great! screw that dumb ELF, I hate it. see, there are not only nuxi zealots, ready to jump on you if you don't use their trash out there.

[nullplan]

I know, I know, PE isn't a great choice to begin with

Why? To my knowledge, PE is perfectly capable of encapsulating the problem of mapping a file into memory. And you don't even want to do that, you are only loading a kernel into memory, which is different, and easier. I don't see any reason to decry PE from a technical perspective at that point.

Now, when we get to DLLs, that's a different matter, but frankly, dynamic linking is a mess everywhere, only it's slightly less of a mess in some places.

IMHO, PE is great! screw that dumb ELF, I hate it. see, there are not only nuxi zealots, ready to jump on you if you don't use their trash out there.

Thus you're making the same mistake with flipped signs. Instead of "MS is bad" it is now "ELF is bad" with exactly as much technical argumentation: none. You have become the very thing you hate. Round of applause.

I will use ELF, because that's what I'm familiar with and what my toolchains produce. And then there's the state of intellectual property regarding these formats (weren't there usage restrictions in the license for the PE spec?) But from a technical point of view, both solve the same problem in a similar way, until we get to dynamic linking, which, as I wrote above, I don't care for.

[bzt]

I don't see any reason to decry PE from a technical perspective at that point.

I agree. Although I as well only use ELF, I've added PE support to BOOTBOOT because (as I wrote in the specification's "Introduction" section):

As of writing, there is no de facto standard, but two most widely used formats: the Executable and Linkable Format, and the Portable Executableformat. It would be unfair to say one is better than the other, since they both represent the same information just in a different way.

And then there's the state of intellectual property regarding these formats (weren't there usage restrictions in the license for the PE spec?)

As far as I know, you are free to use the COFF for sure (all patents if there were any expired by now). PE is just a very minor modification and extension on SysV UNIX COFF, so if you don't use any of those MS specific extensions, MS has no say in the matter, imho. For the records, PE format specification on MSDN does not mention any licensing issues nor usage restrictions, is there another source for PE spec? This is an interesting question, it would be great to sort PE licensing out once and for all.

Cheers,
bzt

[CrypticRasta]

Ok, I have decided to go with bootboot, because freeldr is quite confusing and is GPL'd.
Besides, freeldr is made for reactos and its needs, and I am not trying to roll my own bootloader

[nullplan]

As far as I know, you are free to use the COFF for sure (all patents if there were any expired by now). PE is just a very minor modification and extension on SysV UNIX COFF, so if you don't use any of those MS specific extensions, MS has no say in the matter, imho. For the records, PE format specification on MSDN does not mention any licensing issues nor usage restrictions, is there another source for PE spec? This is an interesting question, it would be great to sort PE licensing out once and for all.

I guess I just misremembered then. I take it back.

[bzt]

As far as I know, you are free to use the COFF for sure (all patents if there were any expired by now). PE is just a very minor modification and extension on SysV UNIX COFF, so if you don't use any of those MS specific extensions, MS has no say in the matter, imho. For the records, PE format specification on MSDN does not mention any licensing issues nor usage restrictions, is there another source for PE spec? This is an interesting question, it would be great to sort PE licensing out once and for all.

I guess I just misremembered then. I take it back.

No, no, I also remember that way, some parts aren't free to use. I just don't remember where I've seen that and which parts. This is another source I've found on webarchive. It could be that terms changed and we both remember wrong and now it's free.

Cheers,
bzt

[zaval]

Thus you're making the same mistake with flipped signs. Instead of "MS is bad" it is now "ELF is bad" with exactly as much technical argumentation: none. You have become the very thing you hate. Round of applause.

But from a technical point of view, both solve the same problem in a similar way, until we get to dynamic linking, which, as I wrote above, I don't care for.

You don't care about dynamic linking, and I do. And it looks awful to me how it's done in ELF and I like how it is in PE. For example that export by ordinal thing, easy to understand, efficient and easy to achieve. This is just an example, popped up from my memory, there are a lot more. I want to have modules that would import/export from each other and that it were done an efficient and elegant way.

I have to admit, I need to learn more about ELF, maybe there could be some ways to achieve with it what I want, after all, I haven't dropped the idea to write my stuff for MIPS (and, maybe even for that noisy RISCV, and there are no PE compilers for those yet, so this is the only "advantage" of ELF now - it's availability). But so far, the experience I've had with it ... I don't like it. ELF, it seems, basically forces you to have just one giant executable and forget about the modularity, just like you like.

PE is just a very minor modification and extension on SysV UNIX COFF

sigh, bzt, as always - massive fart in the puddle. All the really used info in PE is in the Optional Header. COFF header is just a legacy relic. So, you say, that structures described in the Optional Header and it by itself are the same in COFF? Or, that it's a "just a minor modification"?

[nullplan]

You don't care about dynamic linking, and I do. And it looks awful to me how it's done in ELF and I like how it is in PE. For example that export by ordinal thing, easy to understand, efficient and easy to achieve. This is just an example, popped up from my memory, there are a lot more. I want to have modules that would import/export from each other and that it were done an efficient and elegant way.

ELF does not have a concept of exporting by ordinal. Symbols are only identified by their name. There is a symbol type (none, data object, function), but its utility is architecture dependent. However, you can of course implement some naming scheme for your ordinal export functions.

No, fundamental differences between PE and ELF when it comes to dynamic linking are:

• ELF has no concept of "exporting" a function. All external functions are exported. However, there is a patch on top of it called "symbol visibility". So now you can set external symbols to "local" visibility, and they will be used only within that library.
• ELF has no concept of importing a function from a library. You can only declare the need for a library, and later the need for a certain symbol, but nothing binds the symbol to the library. However, this does allow symbol interposition. For example, running a program and replacing the standard malloc with Electric Fence is possible/simple because of this. I have fond memories of reading the source code for a Skyrim mod package and finding out that the special launcher they require us to use is basically just setting LD_PRELOAD. What would have been one line of sh script became a hundred lines of C on Windows.
• The calling sequence through the PLT means that import libraries are unnecessary. And the cdecl calling convention makes the PE symbol name mangling (e.g. "ExitProcess@4") unnecessary. Both of these are positive things, I find.

ELF, it seems, basically forces you to have just one giant executable and forget about the modularity, just like you like.

Oh no, if you want dynamic linking, you can have that. If you avoid symbol versioning, it can even be very modular. The problem here is already the idea of a giant executable. The UNIX model was supposed to be many tiny executables, and modularity by standardized IPC between them (which usually meant pipes transporting text streams). Having a big, complicated system, like Firefox, was not meant to be the UNIX way. But, here we are anyway.

After compilation, modularity is often highly compromised, anyway. Swap out a library version at your peril. However, that is not really a difference between ELF and PE. You can only change libraries as long as binary compatibility was maintained. No, to me, modularity is something achieved at the source level. Do you want to render your text using Pango/Cairo or Xft, that sort of thing. And that is basically fixed in place once the code is compiled, unless you make it a runtime switch. But that would be wasteful, having two code blocks to do the same thing, and only one of them is ever in use.