On Sat, 24 Feb 2007 23:02:20 -0800, Walter Bright wrote:

> John Reimer wrote:
>> That was my conclusion, even though win32 DLL's are a headache in there own right compared to elf shared libraries of other platforms.  At least DLL's can be accessed regardless of format (as long as they are C based).
> 
> Windows DLL's are in Windows PE format. The file format used for object files has no relationship to it.


I don't know the specifics, obviously, of what makes a dll tick.  But I did know it did not matter one iota, because we can load the symbols easily enough with system calls.  So the result is the same :).

-JJR

On Sat, 24 Feb 2007 22:33:11 -0800, Walter Bright wrote:

> 
> Why does Mingw do coff on Win32, while the gcc tools everywhere else do elf? This makes no sense to me.


It seems that elf is an object /and/ executable format, so it requires support from the OS somehow.

Whereas coff is merely an object format and PE appears to be windows executable format.

That may be the reason that mingw went coff instead, even it it isn't compatible with MS coff objects.

-JJR

John Reimer wrote:
> On Sat, 24 Feb 2007 22:33:11 -0800, Walter Bright wrote:
>> Yes. Elf (for object files, anyway) is not operating system dependent.
> I can see that this is true in theory only.  I don't recall
> seeing any practical examples of it.

Having implemented an Elf object file generator and dumper, I can say that there aren't any OS dependencies in it.

> Does the Windows OS care about object format once a binary is linked into
> an executable (ie, the OS exec loader)?

It cannot because it never sees the obj file.

> Is there an instance where object
> format might be of interest to the OS?

It's the linker's job to create an exe file in the format recognized by the OS. Just like the OS never sees source code, it doesn't see object files either.

John Reimer wrote:
> On Sat, 24 Feb 2007 22:33:11 -0800, Walter Bright wrote:
> 
>> Why does Mingw do coff on Win32, while the gcc tools everywhere else do elf? This makes no sense to me.
> 
> 
> It seems that elf is an object /and/ executable format, so it requires
> support from the OS somehow.

If you don't want to take my word for it, ok, but object files output from C, C++, and D compilers are not executable - not on Windows or Linux.

> Whereas coff is merely an object format and PE appears to be windows
> executable format.

PE is similar to coff, but that doesn't mean you can run coff object files.

> That may be the reason that mingw went coff instead, even it it isn't
> compatible with MS coff objects.

John Reimer wrote:
> On Sat, 24 Feb 2007 22:33:11 -0800, Walter Bright wrote:
> 
>> Why does Mingw do coff on Win32, while the gcc tools everywhere else do elf? This makes no sense to me.
> 
> 
> It seems that elf is an object /and/ executable format, so it requires
> support from the OS somehow.  

Only if you use the executable format. I don't see any reason it couldn't be used as an object format (unless PE executables need information ELF has no way to represent).

> Whereas coff is merely an object format and PE appears to be windows
> executable format.
> 
> That may be the reason that mingw went coff instead, even it it isn't
> compatible with MS coff objects.

IIRC mingw is compatible with *some* MS .lib files. It may be just import libraries, and/or just C libraries.
I remember there being *-msvc and *-mingw .libs for one library (I think it was Allegro or SDL or some such) where the difference was _what they were compiled with_, not _what they could be used with_. In fact, IIRC it was recommended to use the *-msvc libs even for mingw...

Walter Bright wrote:

> John Reimer wrote:
>> On Sat, 24 Feb 2007 22:33:11 -0800, Walter Bright wrote:
>> 
>>> Why does Mingw do coff on Win32, while the gcc tools everywhere else do elf? This makes no sense to me.
>> 
>> 
>> It seems that elf is an object /and/ executable format, so it requires support from the OS somehow.
> 
> If you don't want to take my word for it, ok, but object files output from C, C++, and D compilers are not executable - not on Windows or Linux.

Actually it is possible to dynamically link static ELF object files, although it is highly impractical and very slow. As I'm sure you know, on all OS'es using ELF, ELF is used for all stages, static object files, relocatable object files, shared object files (.so and thus a shared library) and executables. The difference is in which sections are present and in some cases, what content they have.

I think it is a good idea to have the same (and actually fairly short) spec for all these formats, it makes it easier to understand a larger portion of this part of the system in depth. I also believe the executables and shared objects are considered to be very efficient, and so it is likely that there has been a compromise on behalf of static object files, making them somewhat more complex.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Bill Baxter wrote:
> Thinking about it, it might actually seem like a better deal if you said it was $15 for coff2omf and obj2asm, and the rest of the stuff is thrown in for free.  As it is the web page seems to imply that coff2omf is about equal to chmod in terms of programming effort and is contributing equally to the cost.

or let's say you support walter's multi-year effort for D by buying the
package, no matter it's content. i'd buy a megabyte of white noise for
that matter ;)
but i found that EUP's grep tool is even more useful than white noise...

Walter Bright wrote:
> Since I have to support Elf anyway, it still leaves me supporting two formats.
> 

I take from this that you plan on dumping OMF support on DMD for Windows and generate ELF .obj on both platforms. Right?

Wouldn't that defeat the purpose of:

> Uses Existing Tools
>
> D produces code in standard object file format, enabling the use of
> standard assemblers, linkers, debuggers, profilers, exe compressors,
> and other analyzers, as well as linking to code written in other
> languages.

http://www.digitalmars.com/d/overview.html

I haven't seen any linker / librarian on windows that support ELF.

Also, I think this change will adversely affect DDL (http://dsource.org/projects/ddl/) since it loads the .obj files and links them directly into the application.

Jarrett Billingsley wrote:
> Why is that free with the Linux distro, though?  :( 

The same reason the Linux kernel is free on Linux and closed-source on Windows.

On Sun, 25 Feb 2007 01:26:12 -0800, Walter Bright wrote:

> John Reimer wrote:
>> On Sat, 24 Feb 2007 22:33:11 -0800, Walter Bright wrote:
>> 
>>> Why does Mingw do coff on Win32, while the gcc tools everywhere else do elf? This makes no sense to me.
>> 
>> 
>> It seems that elf is an object /and/ executable format, so it requires support from the OS somehow.
> 
> If you don't want to take my word for it, ok, but object files output from C, C++, and D compilers are not executable - not on Windows or Linux.
> 


Wait wait... I didn't mean to say that the elf files output by dmd are
directly executable, but elf files (if they are still considered
such) output by the linker stage are (dynamic or otherwise). :P  How much
does ld change these files?  I imagine they are in some class of elf format
after they go through the linker so that they can be considered
executable.  If the file format of the output file continues to be called
elf than elf effectively has an object and executable format.


>> Whereas coff is merely an object format and PE appears to be windows executable format.
> 
> PE is similar to coff, but that doesn't mean you can run coff object files.
> 


Well no, I realize that I can't up and run an object.obj if I want to. :p

-JJR