Implementing a new executable format

[csezol]

It's possible that this will be too much for my experiences, but anyway, I'd like to try..
Is there a tutorial on implementing new executable formats ? How is this done ? Is it part of the kernel, or i need to write a linker, to link files of that type, than add support to it in the kernel ? Please help..

[Solar]

You will need:

• an executable loader supporting that format, for your kernel;
• a linker backend capable of generating that format;
• depending on what will make your format special, you'll have to rewrite / adapt tools further "upstream" to support those features (assembler, compiler, debugger).

[csezol]

Ok.. I'llgive it a try.. anyway, I still think I need an example.. is there one, (re)implementing an executable format..?

[Brendan]

Hi,

• an executable loader supporting that format, for your kernel;
• a linker backend capable of generating that format;
• depending on what will make your format special, you'll have to rewrite / adapt tools further "upstream" to support those features (assembler, compiler, debugger).

I typically extend the "flat binary" format by adding a little OS specific header to it. This means that the OS needs no linker backend, and it works fine with existing tools (as long as you can trick GCC/GAS/LD into generating the header, which isn't too hard).

The problem is that it won't support relocateable binaries or shared libraries/DLLs, but I don't want that sort of thing anyway.

I guess what I'm saying is that the minimum you'd need is "rep movsd", but you can always do more if you want...


Cheers,

Brendan

[csezol]

would somebody gimme a link to a tutorial on this ? ???

[Kemp]

I doubt you're going to find a tutorial on implementing your own executable type, most people who do this (beyond a simple header with some OS specific info in it) do it because they have a specific need for something that doesn't already exist.

[csezol]

ok..
if you ask why am i trying to do all these, the answer is simple: i wanna learn.

[Kemp]

There are a few things that are commonly found in headers (though they are almost always optional):

• An indication of the address the executable expects to be loaded at, or possibly...
• Relocation tables that have a list of what offsets within the data/code need to be changed depending on the address the executable is actually loaded at.
• Information such as a description of the executable or the company that created it.
• The offsets of the code and data areas.

Plus any others that I can't think of off the top of my head.

Descriptions of some existing formats can be found here

[Pype.Clicker]

http://clicker.sourceforge.net/wiclicke ... iveProgram

http://clicker.sourceforge.net/docs/htm ... entry.html

This is all i have to offer about my own "program structure" ... i indeed had to write converters that translate a COFF or ELF binary into a suitable .PROG ...

http://cvs.sourceforge.net/viewcvs.py/c ... tools/pmk/

yet, that's far from being a tutorial, for the very reason that i never thought anyone could need to know why i decided to go that way

[dh]

try expanding on an existing format. My OS design (not on paper) calls for security to be embedded into the executable file, but ELF doesn't really have all of that. Simple solution: play with an existing format! I read that COFF is relativly basic (doesn't support Position independant code iirc) so it may be a good place to start. The orginal dos format (don't remember name, but it's in the OSfaq) looks VERY simple. I havn't viewed anything about it yet though, so i don't know.

Cheers, DH.

[Pype.Clicker]

yep, probably if i was to do it again, i'd be tempted to embed those "extra information" in a specific section of ELF format ...