Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site talcott.UUCP
Path: utzoo!linus!decvax!genrad!panda!talcott!lotto
From: lotto@talcott.UUCP (Jerry Lotto)
Newsgroups: net.micro,net.micro.16k,net.micro.pc
Subject: Re: MS-DOS object code format
Message-ID: <575@talcott.UUCP>
Date: Wed, 5-Mar-86 09:26:47 EST
Article-I.D.: talcott.575
Posted: Wed Mar  5 09:26:47 1986
Date-Received: Sat, 8-Mar-86 08:12:02 EST
References: <549@imag.UUCP> <678@uwvax.UUCP>
Organization: Harvard Univ. Chem. Dept.
Lines: 26
Keywords: MS-DOS, object code, linker input
Xref: linus net.micro:12764 net.micro.16k:408 net.micro.pc:7046
Summary: Source for inf. and re: uSoft .OBJ format

In article <678@uwvax.UUCP>, ericf@uwvax.UUCP (Eric Feigenson) writes:
> While someone is looking for a reference to MS-DOS object file formats...
> 
> I recently was trying to analyze the .OBJ files under MS-DOS.  I got
> the "8086 Relocatable Object Module Formats" document from Intel
> (Order number 121748-001) to aid me in my quest.  However, there
> seems to be a critical difference in the .OBJ format described in the
> document, and the .OBJ files I found generated by the Microsoft C Compiler.

	The MS-DOS programmers ref. 8411-310-02 or later, Chapter 6
has the information you are looking for. In a nutshell:

Segment, group and type definition records, all symbol definition records
and the module end record differ from the Intel specification.
Specifically - the Microsoft linker uses TYPDEF records for communal
variable allocation only (contrary to Intels specs). If the TYPDEF
referenced by some EXTDEF does not qualify a variable as communal,
a matching PUBDEF is expected. Alternatively, if a PUBDEF matches
a communal variable definition, it overrides the original assignment.
-- 

Gerald Lotto - Harvard Chemistry Dept.

 UUCP:  {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lhasa!lotto
 ARPA:  lotto@harvard.EDU
 CSNET: lotto%harvard@csnet-relay