From:	elf AT netcom DOT com (Marc Singer)
Message-Id:	<199605220552.WAA29491@netcom4.netcom.com>
Subject:	Re: Win32 COFF
To:	martynas DOT kunigelis AT vm DOT ktu DOT lt (Martynas Kunigelis)
Date:	Tue, 21 May 1996 22:52:56 -0700 (PDT)
Cc:	djgpp AT delorie DOT com (DJGPP List Alias)
In-Reply-To:	<199605200721.DAA24125@delorie.com> from "Martynas Kunigelis" at May 20, 96 09:53:41 am
MIME-Version:	1.0

>   Is Win32 object file format (COFF I assume) compatible with DJGPP
> .o format?  Because if it is not, I see no reason why not have
> ELF-based Win32 support.

Exactly.

> Because a new linker would be necessary anyway, why not write a
> linker producing PE/COFF executables/dlls out of ELF object files?

True, again.

> Plus AFAIK ELF does not necessarily imply PIC, only shared libraries
> are the case. 

No. All parts of the program need to adhere to the PIC conventions so
they can call each other.

> Anyway, I am not sure what advantages ELF has over COFF, but if it
> has some, I think it is possible to have Win32 and ELF friendly.

Probably not.  We'd have to thunk between Windows and the ELF code so
that the registers are properly configured.  In fact, it would be very
similar to the way that the old Windows prolog/epilog code worked.

> AFAIK ELF is exclusively designed for Intel CPUs, also
> someone said debug info is more flexible. 

Better not tell Sun that.  %^)  It was designed for SVR4 which likely
to be targeted for something other than the x86. 

> Also we have its complete specification. I do understand the COFF
> structure by now, but for future maintenance, better documented and
> advanced format would be better I think.

One of the bigger grips with COFF is that it is not standard from
platform to platform.  Everyone and here mother has a variant which is
difficult to distinguish from every other.  For example, you cannot
tell the endian-ness from reading the file unless you know a-priori
where it was created, or if you make a good guess.

Marc

- Raw text -