OSDev.org

Which are pros and cons of PE and ELF file formats when they are used for executables, shared libraries and device drivers?

Vote and give your opinion!

The differences between them are far too intricate to be shown in such a large-grained vote. I'm at work at the moment, but may post more about it later.

Can't speak for PE, but so far ELF has been a pain in the @$$. I got it working but it wasn't pleasant at all

What's faster? Binary!

Time to beat Brynet-Inc to the point
Neither is faster. Or ELF is faster because PE is for windows and windows is slow.
Neither is smaller, or ELF is smaller because everything written for windows is bloatware.
Therefore, I want to cast magic missile at this poll.

I prefer ELF, because its better documented, better supported, and free from several "features" that are only relevant to windows environments. That said, I have written code to deal with executables for both formats, and the ELF format is IMO much easier to deal with. However, I can't vote that.

a new executable file format may be implemented for new OS. for example the one that takes all good (or necessary) from both pe and elf with all the unnecessary stuff wiped out. But to choose between pe and elf... I prefer elf. but all my executables are still plain binary

I must admit Combuster, I also got ELF32 and ELF64 working, it's documented very good, and it has a clear structure.

zhak wrote:a new executable file format may be implemented for new OS.

...requiring work on all parts of the toolchain involved to support the new format.

I'd vote "ELF is faster" because it will allow you to solve the format issues fastest (due to available documentation and tools), but I doubt that's what the OP had in mind.

If only ELF has an extension ... (so I don't have to parse each file just to know what it contains. Read: UNIX stupify)

Well, extension or not is entirely up to you, isn't it? I think extension-less-ness is quite neat. Who cares if it's a ELF exe, a Perl script or a Java application, as long as it starts correctly? (And the loader has to load 'em anyway, so whether it has to look into the filename or the first couple of bytes of the file itself doesn't matter.) A filename extension is redundant information, and we know what that implies...

While my perspective may be somewhat biased or even incorrect, I'm pitching in my 2c ...

1) PE Speed vs. ELF Speed
It highly depends on situation and, context. A PE loaded precisely where it was meant to be loaded (ie: .dll, somewhere in memory, where it wanted to be originally) will execute faster than an ELF loaded to the same place. HOWEVER, Rebasing a PE is horribly slow (ie: putting .dll somewhere else, where it wasnt intended).

edit: decent explanation :: http://en.wikipedia.org/wiki/Portable_Executable

Also, from what I can discern, .dlls arent quite as sharable as ELF Shared Objects. An ELF Shared Object can be in many address spaces, simultaneously, mapped
at completely different regions in each address space (thanks to the .got.plt, .got). Not to mention relocating an ELF is faster.

2) PE Memory vs. ELF Memory
Lately I've been doing a lot of work, investigating both formats for my crazy project (yes, I'm elderK). Anywho, sure, ELF has a lot of stuff crammed into it. 80% of that stuff you can strip. The remaining 20% can be reclaimed after loading the binary, in some way, without compromising sharability.

I'm not sure if that can be said for PE but then again, I havent researched PE as heavily as I have ELF.

3) Laksen "Can't speak for PE, but so far ELF has been a pain in the @$$. I got it working but it wasn't pleasant at all".
I remember talking to you #osdev on Freenode. If I remember correctly, your method of loading ELFs was simply loading the Relocatable files (.o).
Of course that will be a pain in the @$$ - very little of it is in the state in which it would normally be! All of the symbols are NOT linked to addresses.
Just a whole bunch of fixups to be performed. AFAIK, For Relocatable Objects (.o), The tracking required exceeds that for Executable / Shared Objects.

4) Finally, to end my "ELF is cool!" spiel, You can create Position-Independent-Executables, too. So you can relocate anything you like!

Oh, and for those who want to see how difficult ELF really is, complete with Dynamic Linking, keep your eyes peeled. I'll release a small program sometime
soon. Basically, my collection of prototype loaders/linkers (created whilst investigating ELF, to gain familiarity). Public domain, of course. If it helps anyone at all, that'd be awesome.

~zeii / elderK

One error in your polling:

You can vote both "PE is faster" and "ELF is faster"; and it will still work.

Potential Solution:
Change your polling information so that you may only choose 1 option, and change the potential answers accordingly:

• PE is both faster and it saves more memory
• PE is faster and ELF saves more memory
• ELF is both faster and it saves more memory
• ELF is faster and PE saves more memory

Hi,

Jeko wrote:Which are pros and cons of PE and ELF file formats when they are used for executables, shared libraries and device drivers?

PE: Designed by Microsoft for Windows. Really useful for executable files on Windows clones.

ELF: Designed by SCO for Unix System V. Really useful for executable files on Unix clones.

BCOS_NFF: Being designed by me for my OS. Really useful for all native (for my OS) file types including (but not limited to) executable files for my OS. Consists of a generic header (file size, magic number, checksum/CRC, file type ID) that is identical for all native file types, optionally followed by an extended header that depends on the file type ID in the generic header.


Cheers,

Brendan

I was designing a format based on the HTMA (Html Application) idea in Windows XP and Vista.
Would composing an app in XML be an idea?
XML header only maybe?

Jeko wrote:Which are pros and cons of PE and ELF file formats when they are used for executables, shared libraries and device drivers?

Vote and give your opinion!

For me, the PE format looks much more simple. It is true that relocating an image (shared library) is required when the image cannot shared between two processes, but I don't think it is *that* slow (AMD64 has even RIP-relative addressing, which makes some of the relocations go away). Of course you have to watch out for some differing fields between PE and PE+ when targeting the x64 platform. And it has some Windows-specific stuff, all of which can safely be ignored.

On the other hand, I still want to develop an ELF loader for my OS (why not?), but it has some concepts unfamiliar to the average Windows developer. Windows does not have a GOT or a PLT, neither all those tricky relocation calculations associated with it... It is true that documentation exists for the format, but it does not explain what is a GOT or a PLT (at least I could not find an explanation).

Bottom line: if you want something simple and fast, develop a custom image format for your OS.