osfree.org

osfadmin

Site Admin

Joined: 24 Nov 2003
Posts: 60
Posted: Sat Oct 28, 2006 1:07 pm

As you know, in the present time various OSes support at least 2 different executable image file format. Originally,
OS/2 doesn't support mechanizm like IIF and it is not possible in easy way to add support, for example, for ELF or
PE format. Odin has some approach to implement such support, but for OS it is hack. We want to predict image file
format changing and support of images from other OSes. So, IIF idea was born.

Because we need to support different formats in loader too we need to make, similar to IFS, MicroIFD (Micro Image
File Driver). Personally, I don't think we need more then 64K code to support any of existent image file formats. So,
we need to think, how interoperate with loader .

So, it's time for specification writing

Viking

Joined: 29 Sep 2006
Posts: 42
Location: Sweden
Posted: Sun Oct 29, 2006 7:46 am

osfadmin wrote: As you know, in the present time various OSes support at lease 2 different executable image file format. Originally,
OS/2 doesn't support mechanizm like IIF and it is not possible in easy way to add support, for example, for ELF or PE
format. Odin has some approach to implement such support, but for OS it is hack. We want to predict image file
format changing and support of images from other OSes. So, IIF idea was born.

Because we need to support different formats in loader too we need to make, similar to IFS, MicroIFD (Micro Image
File Driver). Personally, I don't think we need more then 64K code to support any of existent image file formats. So,
we need to think, how interoperate with loader .

So, it's time for specification writing

Ok. The hard part. One thing, L4 seems to have an ELF loader. Don't know if it's builtin or designed as a separate
component.

What operations is an IIF going to need? Something like read file, parse file, relocate (or is that to specific, if it's
about java class files). Should the image files be separated in two different sets with one as "normal" exe files and
second interpreter files, which needs an external program to run them.

I know that GNU/Linux has some sort of support for image formats.

What do you think?

osfadmin

Site Admin

Joined: 24 Nov 2003
Posts: 60
Posted: Sun Oct 29, 2006 12:14 pm

Viking wrote:

osfadmin wrote: As you know, in the present time various OSes support at lease 2 different executable image file format. Originally,
OS/2 doesn't support mechanizm like IIF and it is not possible in easy way to add support, for example, for ELF or PE
format. Odin has some approach to implement such support, but for OS it is hack. We want to predict image file
format changing and support of images from other OSes. So, IIF idea was born.

Because we need to support different formats in loader too we need to make, similar to IFS, MicroIFD (Micro Image
File Driver). Personally, I don't think we need more then 64K code to support any of existent image file formats. So,
we need to think, how interoperate with loader .

So, it's time for specification writing

Ok. The hard part One thing, L4 seems to have an ELF loader. Don't know if it's builtin or designed as a separate
component.

What operations is an IIF going to need? Something like read file, parse file, relocate( or is that to specific, if it's
about java class files). Should the image files be separated in two different sets with one as "normal" exe files and
second interpreter files, which needs an external program to run them.

I know that GNU/Linux has some sort of support for image formats.
What do you think?

Ok. In general we propose for MicroIIF to use RAW/BIN file format. MicroIIF contains only one function:

int load(char far *image, unsigned long size, char far *load_addr, struct exe_params *p);

and returns exe_params with list of functions which can be called.

This is according MicroIIF. Not ideas yet about whole IIF.

MicroIIF for boot loader.

valerius

Joined: 03 Apr 2005
Posts: 50
Location: Elizovo, Kamchatka, Russia
Posted: Sun Oct 29, 2006 12:50 pm

Viking wrote: Ok. The hard part One thing, L4 seems to have an ELF loader. Don't know if it's builtin or designed as a
separate component.

L4 itself is just a microkernel. It provides only minimal set of mechanisms and abstractions. So, ELF support
is not part of a microkernel, it can be implemented as a server, or a set of small servers. For example, in L4
environment (a set of user-level services on top of L4/Fiasco microkernel, used in DROPS operating system)
there is "exec" server, which interprets ELF binaries, "loader" server which interprets loader scripts and allocates
resources, and some more servers, involved in loading, for it.

We must to design a similiar infrastructure with possibility to plug in different 'exec' layers for different EXE
formats aka IIF drivers. They must supply a standard set of interfaces, the question of these interfaces (or
API's) is open.

For loader there is a suggestion to make a Micro IFF driver, like MicroFSD. It must only accept an EXE image
(its address in memory), loaded to memory with assistance of MicroFSD, and address to load to. It returns a
structure with entry table of a binary image.

Viking wrote: What operations is an IIF going to need? Something like read file, parse file, relocate( or is that to specific,
if it's about java class files). Should the image files be separated in two different sets with one as "normal"
exe files and second interpreter files, which needs an external program to run them. What do you think?

I know that GNU/Linux has some sort of support for image formats.

Obviously, we need a functions to extract sections from image, to extract resources.

-- To get special info from it. And to load image in memory and relocate it. -- It seems that loading and
relocating must be done at once by one "load" IIF function, like we suggested in micro IIF. But microIIF must
have only load() function, and full-featured IIF must have the same load() function and some additional functions,
e.g. for extracting info from EXE, like resources etc. The load() function in MicroIIF can't do dynamic linking and
to resolve external links and a full-featured IIF must have it. Also, the size of micro IIF is linited to 64 Kb. We
need to think it over. (Not yet)

Yes, we need to decide how to handle Java binaries.

But it seems that linux kernel just allows to set "executable" attribute on java binaries, and then launches Java
VM and passes java class to it. It dowsn't parse java class files, it only loads them and leaves file parsing to Java
VM So, IMHO, there is not something like IIF in Linux. I think that load() in our IIF for Java must only load java
class file and not to relocate -- it does Java VM. But we must supply a standard set of IF functions like load() and
functions, extracting info from binary file. The Java VM must be modified in a special way to call these functions.
And if a class requires another class, Java VM must

call load() for this additional class file.

This is my IMHO.
_________________
WBR,
Valery V. Sedletski