Talk:Object file

Untitled

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)

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)

So, why is it called an "object" file anyway? Is there any historical significance of the word "object"? The reasons for it seem awfully vague to me. —Preceding unsigned comment added by 66.211.10.234 (talk) 12:49, 20 March 2008 (UTC)

Object here is used as a synonym of "goal" or "purpose", as in the object of the assembler. Ham Pastrami (talk) 16:40, 19 July 2008 (UTC)

OMF is an Intel TIS standard. I started out trying to find a reference for the definition of "object file" at the start of the article and ran into a problem. The only cite I can find is from a Google eBook that cites this article as a reference! Everything I've been able to find starts out by assuming the reader knows what an "object file" is.Peter Flass (talk) 18:09, 12 November 2011 (UTC)

Object module

Object module redirects to this article. Is there something special about it compared to object file? --Abdull (talk) 09:50, 29 February 2008 (UTC)

"object module" is IBM-ese. Peter Flass (talk) 18:06, 12 November 2011 (UTC)

Object code != "the stuff in an object file"

Object code is simply the result of compiling source code and isn't necessarily machine code (a number of compilers for functional languages have used C as their object code for example, and javac uses JVM bytecode). The first source I can find online is [1], but I've seen this definition in works dating back to the 60s and I'm sure it's present in a good many works on compilers. 86.10.90.232 (talk) 12:15, 2 May 2008 (UTC)

Agreed. An object file is not necessarily "an organised collection of named objects" but simply the "object" (or result) of the compilation process. Jan1naD ^{(talk • contrib)} 10:45, 3 December 2009 (UTC)

(three years later) I also agree, and I have created the stub Object code, which was previously a thoroughly confusing redirect to Object file. 84user (talk) 16:35, 1 September 2011 (UTC)

It was not "thoroughly confusing". These two concepts ("the output of a compiler" and "a binary file containing machine code and related data") are not that much fundamentally distinct that they warrant separate articles - most of the time they are pretty much equivalent. Even the stub you created describes its subject pretty much the same way as this article. The splitting was completely unnecessary. Though I'd rather see a redirect the other way, from Object file to Object code, as the latter name seems more popular. Ian (87.205.128.127 (talk) 13:34, 17 September 2011 (UTC))

Definition

How about the following as a definition of object file? (with appropriate links, they apparently got lost when I cut and pasted)

"An object file is a file containing relocatable format machine code that is usually not directly executable. Object files are produced by an assembler, compiler, or other language translator, and used as input to the linker.

Additionally, object files may contain metadata such as information to resolve symbolic cross-references between different modules, relocation information, stack unwinding information, comments, program symbols, debugging or profiling information). A linker is typically used to generate an executable or library by combining parts of object files."Peter Flass (talk) 03:38, 13 November 2011 (UTC)

Merger proposal

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result of this discussion was to not merge. —Nils von Barth (nbarth) (talk) 14:22, 3 May 2013 (UTC)

---

See Talk:Object code#Merger proposal for discussion.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.