Talk:Object file

From Wikipedia, the free encyclopedia

This article appears to be a little inconsistent. It starts off saying object formats are intermediate representations, citing COFF and ELF. All good stuff (and although you can execute ELF files, they can contain all the symbolic and linkable stuff that I would suggest designate an object file). It then goes on to state that 'COM' is an object format, which I would suggest it isn't - COM is an executable format, as is PE (which stands for Portable Executable, ). And COM is no simpler than the executable images you would find on ROMs in embedded systems. Any objections to me removing references to COM and PE? There should probably be an article on 'executable image', which also references Executable and Linkable Format, but lists COM, PE, .exe, etc. . --81.106.187.101 22:43, 22 May 2006 (UTC)

An object file is nothing more than code and data with a specific organizational format. Object files include executables, libraries, intermediate compiler files, etc. Depending on the operating system's and compiler chain support ELF, COFF, PE, COM, etc. can be all of these. PE itself is more or less a modified version of COFF which begins with a COM section followed by an extended version of COFF. COM is more or less a single section binary format without any headers expecting to be loaded and executed at a static prespecified address without further processing. You may categorize COM as an 'executable image', but it is still in the catagory of object file format. So, I object to removing COM and PE. Jsmethers 03:37, 23 May 2006 (UTC)

Still not sure. PE, COFF and ELF can support some export of symbols and function entry points, so they can serve the purpose of being intermediate representation, and undergo further (possibly dynamic) linking. COM doesn't allow this. But I take your point about PE being intermediate and COFF-like. Indeed, using depends.exe on any (non-solipsistic) Windows executable will reveal that it needs to dynamically link to user.dll etc. So I suppose my point is that an object file will need further linking. Is that fair? --81.106.187.101 03:58, 24 May 2006 (UTC)

No. Your definition of object file is very narrow, and does not fit with the use of 'object file' in industry or academia. An object file is a very broad term which can refer to just about any sort of file containing code or data ment to be integrated into a computer program. It is NOT mutually exclusive with 'executable image', but rather a super set there of. An ELF file may also represent an 'executable image' in which case the only difference with COM is headers giving it the ability to dynamically specifiy where in memory it was pre-linked for, whereas COM simply uses a standard static location. COM is an 'intermediate representation' which still needs to be loaded at the correct memory address to be executed. If anything, the article should elaborate on what an 'intermediate representation' is to remove this ambiguity. Jsmethers 05:36, 24 May 2006 (UTC)

Fair comment. I'm labouring under the notion that a .o or .obj always needed to pass through a linker to be turned into something useful. This is still very much the case on embedded systems, where the distinction is (I believe) valid, but I now see that on larger systems, which feature OSs that can load applications, compile-time or run-time linking is almost a matter of taste, so the notion of object files covers all these possibilities.

You suggest some more detail about 'intermediate representation' may help, and I wholeheartedly agree. This would also help clarify the situation with executable images for embedded platforms where object files simply will not do. --81.106.187.101 03:33, 27 May 2006 (UTC)

What is the file format for .obj files produced by Microsoft compilers? If it's PE, then PE is an object file format as well as an executable file format (just as a.out, COFF/ECOFF/XCOFF, ELF, and Mach-O are - UNIX systems have traditionally used the same file format for .o files and executable images). The Matt Pietrek articles referred to by the Portable Executable page speak of COFF .obj files, which might mean that object files are just COFF and executable files are COFF plus a PE header, in which case PE would only be an executable format. Guy Harris 02:01, 23 May 2006 (UTC)

With the modern versions, it's PE. Dumpbin.exe works just fine on .objs, however other toolchains (e.g. Borland) have something proprietory and non-PE --81.106.187.101 03:58, 24 May 2006 (UTC)

So it appears that PE is an object file format both in the wide sense of containing object code and the narrow sense of being compiler/assembler output that can be linked with other object files and libraries into an executable. Guy Harris 19:31, 24 May 2006 (UTC)

BTW, there already is an article on executable files/images. Guy Harris 02:01, 23 May 2006 (UTC)

Ah. So there is. --81.106.187.101 03:58, 24 May 2006 (UTC)

EXE is not properly a file format. There have been at least three Microsoft formats which used that "extension" (of which the latest is properly called PE after its Magic_number, in addition to numerous DEC operating systems and IBM's OS/2, all of which had their own formats. 18.24.0.120 06:18, 18 Jan 2004 (UTC)

Do you have credible references for this on the web? --Siva1979^{Talk to me} 16:36, 5 May 2006 (UTC)

For at least one (formerly) DEC operating system (now HP), namely OpenVMS, there's Chapter 3 of the OpenVMS User's Manual, which says:

A program, also called an image or an executable image, is a file that contains instructions and data in machine-readable format. Some programs are associated with a DCL command. For example, when you type the DCL command COPY, the system runs the program SYS$SYSTEM:COPY.EXE. Some programs are started by entering the DCL command RUN followed by the program name.

Image files can be supplied by the operating system or by you and usually have the file type .EXE. You cannot examine an image file with the DCL commands TYPE, PRINT, or EDIT because image files do not consist of ASCII characters. (Text files contain ASCII characters, which are a standard method of representing the alphabet, punctuation marks, numerals, and other special symbols.)

For OS/2, there's the site for Odin, software that "allows users to run Win32 (Windows 95 and Windows NT) applications in OS/2 Warp operating system natively, almost as if they were intended to be OS/2 applications in the first place"; that page says

Binary compatibility is achieved by converting Windows EXE and DLL files (applications are made of those) into the format that OS/2 uses. Conversion can be permanent, or it can be done transparently on runtime, when an application is started. Conversion and loading of Win32 programs, basicaly, consists of:

• Converting PE (Portable Executable - Win32 binaries) objects in OS/2's LX (Linear eXecutable) format.
• Reassembling them in memory in the way OS/2 applications are supposed to be assembled.

The program that will permanently convert binaries (EXE and DLL files) is called PE2LX.EXE.

indicating both that OS/2's executable format is not the same as that of Windows and that OS/2 executables have a suffix of ".EXE".

And as for Microsoft formats, there's this article from the Microsoft Systems Journal, which says

If the file begins with an MS-DOS MZ executable, the executable may be just an MS-DOS stub for a newer type of executable. The file might really be a 16-bit Windows executable (NE), a Win32 executable (PE), an OS/2 executable (LX), or a VxD (LE).

and at least suggests that those files are .EXE files. Guy Harris 18:00, 5 May 2006 (UTC)

[edit] Missing information

There should be something here on the old DOS .OBJ files, which I believe were in a format called OMF (although I'm pretty sure it's not the same OMF described already). I also think the "proprietary" format used by Borland toolsets (as mentioned above) is the same format. JulesH 11:07, 2 January 2007 (UTC)

I've done some digging and located some details. I've created Relocatable Object Module Format and will now link it in. JulesH 14:22, 2 January 2007 (UTC)