Documentation for OBJSCN.C Version 1.01


  This program is based on information from the article ".OBJ LESSON" in
the October 1985 PCTJ, and uses the notation from that article.  Certain
errors in the article, however, became apparent while implementing the
program, so be cautious in drawing conclusions when the program code and
the article appear to contradict each other.

  The rather cryptic notation used in the FIXUPP record translations refers
to the "frame" location to undergo the fix, the "target" location involved,
and the method used by the linker to determine these. In the report, the
"ofs=" value is the offset within the previous LEDATA record to which this
FIXUPP refers.

  Fx and Tx refer to Frame and Target methods respectively. T0-T3 indicate
index/displacement; T4-T7 and F0-F3 indicate index only. The low two bits
indicate SEG if 00, GRP if 01, or EXT if 10; that is, T6 indicates that the
target is specified by an index into the EXT name list.

  The "fi" and "ti" entries refer to Frame/Target index values if the method
involves a GRP, SEG, or EXT reference, or to the thread ID number if the
method indicates a previous-thread reference (method>7). The "tos=" field,
if present, is the target displacement within the segment indicated by the
"ti" index or the thread ID number.

  The GRPDEF record is not decoded in this version. The first value shown is
the LNAMES index of the name of the group being defined. The "ff" bytes
indicate nothing; the bytes following each "ff" are the SEG indices of the
segments which constitute the group.

  Neither is the MODEND record decoded. A 2-byte record with value "00 74"
is normal end-of-module with no specified entry address. A longer record with
initial byte "c1" indicates that an entry address is specified. The last
three bytes of the record (before the checksum byte) indicate the segment
index and offset of the entry point.

  Any record type not recognized by the program will be reported as a 2-digit
hex value, followed by the decimal length of the record. The bytes of the
record will then be reported as a stream of hex values. The sole exception is
a record type of "00"; this value, not used by any OBJ format, is ignored by
the program, to permit skipping over null filler in MS-format LIB files.

  Direct questions and comments to Jim Kyle, 76703,762.
					..jk..		12/02/86

  addendum--

  After the package was uploaded to MSOFT, I received the following message
from Daniel Cerutti. His additions have been included in this new version
(version 1.01) with much gratitude!

Date:  04-Jan-87 07:22 CST
From:  Daniel Cerutti [76267,426]
Subj:  OBJSCN - Object file dump

Jim --
 
I have downloaded OBJSCN.ARC. This is a very useful tool for
examining object files. I have started a similar development
as yours a few weeks ago, but I had no time to continue it.
So may be I can help you continuing the development of OBJSCN.
The reference document I use is the Microsoft MS-DOS Programmer's
Reference (Document no. 8411-310-02, part no. 036-014-012) which
includes the description of Intel Object Module Format as used
by the Microsoft linker.
 
Below is additional code to handle comment records class used
by the linker. I have included support for the dynamic link
records used by the DOS 4 / Windows linker (was documented
in the material from the Microsoft Windows developer's conference).
 
I would like to include code for the new records type used by
Microsoft C 4.0 (type B0 hex), but have no doc on it. These
records define global data, including data size definitions,
but I am not sure of the format.
 
Sorry for my english (I am swiss). I hope this is helpful
to you. Regards.
                         Daniel Cerutti.
 
                         Compuserve: 76267,426 
                         BIX: dcerutti