I found some info at this link:
If you dont want to read the link:

Differences Between PE and COFF OBJ Files
There are two portions of the PE file that are not used by the operating system. These are the COFF symbol table and the COFF debug information. Why would anyone need COFF debug information when the much more complete CodeView information is available? If you intend to use the Windows NT system debugger (NTSD) or the Windows NT kernel debugger (KD), COFF is the only game in town. For those of you who are interested, I've included a detailed description of these parts of the PE file in the online posting that accompanies this article (available on all MSJ bulletin boards).

At many points throughout the preceding discussion, I've noted that many structures and tables are the same in both a COFF OBJ file and the PE file created from it. Both COFF OBJ and PE files have an IMAGE_FILE_HEADER at or near their beginning. This header is followed by a section table that contains information about all the sections in the file. The two formats also share the same line number and symbol table formats, although the PE file can have additional non-COFF symbol tables as well. The amount of commonality between the OBJ and PE EXE formats is evidenced by the large amount of common code in PEDUMP (see COMMON.C on any MSJ bulletin board).

This similarity between the two file formats isn't happenstance. The goal of this design is to make the linker's job as easy as possible. Theoretically, creating an EXE file from a single OBJ should be just a matter of inserting a few tables and modifying a couple of file offsets within the image. With this in mind, you can think of a COFF file as an embryonic PE file. Only a few things are missing or different, so I'll list them here.

COFF OBJ files don't have an MS-DOS stub preceding the IMAGE_FILE_HEADER, nor is there a "PE" signature preceding the IMAGE_FILE_HEADER.
OBJ files don't have the IMAGE_OPTIONAL_HEADER. In a PE file, this structure immediately follows the IMAGE_FILE_HEADER. Interestingly, COFF LIB files do have an IMAGE_OPTIONAL_HEADER. Space constraints prevent me from talking about LIB files here.
OBJ files don't have base relocations. Instead, they have regular symbol-based fixups. I haven't gone into the format of the COFF OBJ file relocations because they're fairly obscure. If you want to dig into this particular area, the PointerToRelocations and NumberOfRelocations fields in the section table entries point to the relocations for each section. The relocations are an array of IMAGE_RELOCATION structures, which is defined in WINNT.H. The PEDUMP program can show OBJ file relocations if you enable the proper switch.
The CodeView information in an OBJ file is stored in two sections (.debug$S and .debug$T). When the linker processes the OBJ files, it doesn't put these sections in the PE file. Instead, it collects all these sections and builds a single symbol table stored at the end of the file. This symbol table isn't a formal section (that is, there's no entry for it in the PE's section table).

An OBJ does not have all the info an EXE has. I figured that, the linker adds the MZ header and some other stuff.

I've been looking through Winnt.h. Some of the structures are defined there.

Does anyone have any links or info for making OBJ files??

I'm a bit confused because of stuff like this: (from above)

Both COFF OBJ and PE files have an IMAGE_FILE_HEADER at or near their beginning.

Uhhhh, okay.... Why would it not always be in the same place?

Does anyone have the MS-COFF structure in non-tutorial format? (Broken into little bits).
I would like to see a basic one as it appears in memory. Just a list of the fields.

Posted on 2004-02-12 08:54:33 by ThoughtCriminal

here's a link collection that I've found while browsing the net, when i was studying the PE.

Matt Pietrek (Peering inside the PE)


Matt Pietrek: An In-Depth Look into the Win32 Portable Executable File Format


Matt Pietrek: Inside Windows: An In-Depth Look into the Win32 Portable Executable File Format, Part 2




LUEVELSMEYER's description about PE file format


And "The" big archive (I think it's the bible of the PE/COFF), with everything about the PE and COFF certifications (from Microsoft.). You'll find all you want to know about the PE and the COFF file format:

PE and COFF specifications


Hope you'll find it interesting.

Regards, Neitsa.
Posted on 2004-02-12 09:26:47 by Neitsa
Some additional info, the DJGPP COFF format (very very similar to ms-coff): http://www.delorie.com/djgpp/doc/coff/

Uhhhh, okay.... Why would it not always be in the same place?

Because .obj files don't have MZ stubs? :)
Posted on 2004-02-12 09:43:16 by f0dder

Because .obj files don't have MZ stubs?

Ahh thanks. The way it was written did not make it clear to me.

Some additional info, the DJGPP COFF format (very very similar to ms-coff):

Is it compatible? Would an exe made from a DJGPP obj file run on Windows?
Posted on 2004-02-12 11:32:07 by ThoughtCriminal
DJGPP doesn't create PE files, and it uses a dos extender approach - but those executables do run under windows. It uses a "floating-segment" approach, ie not a flat memory model, to avoid relocations etc - some apps use a "hack" to enable flat adressing though, especially for VESA stuff, and NT doesn't like this very much ;)

The ms-coff and djgpp-coff object formats are *almost* compatible - however, some relocation formats are handled a bit differently. One of them (iirc, ms) has DWORD 0 as the data and depends on the linker to do a full symbol fixup, while the other format has the unrelocated reference and depends on the linker to add the 'delta value' - and thus you can't link dj-coff with ms link or vice verca. It should be easy enough to write a tool to fix up the relocs, though.
Posted on 2004-02-12 14:31:54 by f0dder