home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS 1992 September / Simtel20_Sept92.cdr / msdos / pgmutl / objsc101.arc / OBJSCN.TXT < prev   
Text File  |  1987-01-05  |  4KB  |  85 lines
  1.  
  2.         Documentation for OBJSCN.C Version 1.01
  3.  
  4.  
  5.   This program is based on information from the article ".OBJ LESSON" in
  6. the October 1985 PCTJ, and uses the notation from that article.  Certain
  7. errors in the article, however, became apparent while implementing the
  8. program, so be cautious in drawing conclusions when the program code and
  9. the article appear to contradict each other.
  10.  
  11.   The rather cryptic notation used in the FIXUPP record translations refers
  12. to the "frame" location to undergo the fix, the "target" location involved,
  13. and the method used by the linker to determine these. In the report, the
  14. "ofs=" value is the offset within the previous LEDATA record to which this
  15. FIXUPP refers.
  16.  
  17.   Fx and Tx refer to Frame and Target methods respectively. T0-T3 indicate
  18. index/displacement; T4-T7 and F0-F3 indicate index only. The low two bits
  19. indicate SEG if 00, GRP if 01, or EXT if 10; that is, T6 indicates that the
  20. target is specified by an index into the EXT name list.
  21.  
  22.   The "fi" and "ti" entries refer to Frame/Target index values if the method
  23. involves a GRP, SEG, or EXT reference, or to the thread ID number if the
  24. method indicates a previous-thread reference (method>7). The "tos=" field,
  25. if present, is the target displacement within the segment indicated by the
  26. "ti" index or the thread ID number.
  27.  
  28.   The GRPDEF record is not decoded in this version. The first value shown is
  29. the LNAMES index of the name of the group being defined. The "ff" bytes
  30. indicate nothing; the bytes following each "ff" are the SEG indices of the
  31. segments which constitute the group.
  32.  
  33.   Neither is the MODEND record decoded. A 2-byte record with value "00 74"
  34. is normal end-of-module with no specified entry address. A longer record with
  35. initial byte "c1" indicates that an entry address is specified. The last
  36. three bytes of the record (before the checksum byte) indicate the segment
  37. index and offset of the entry point.
  38.  
  39.   Any record type not recognized by the program will be reported as a 2-digit
  40. hex value, followed by the decimal length of the record. The bytes of the
  41. record will then be reported as a stream of hex values. The sole exception is
  42. a record type of "00"; this value, not used by any OBJ format, is ignored by
  43. the program, to permit skipping over null filler in MS-format LIB files.
  44.  
  45.   Direct questions and comments to Jim Kyle, 76703,762.
  46.                     ..jk..        12/02/86
  47.  
  48.   addendum--
  49.  
  50.   After the package was uploaded to MSOFT, I received the following message
  51. from Daniel Cerutti. His additions have been included in this new version
  52. (version 1.01) with much gratitude!
  53.  
  54. Date:  04-Jan-87 07:22 CST
  55. From:  Daniel Cerutti [76267,426]
  56. Subj:  OBJSCN - Object file dump
  57.  
  58. Jim --
  59.  
  60. I have downloaded OBJSCN.ARC. This is a very useful tool for
  61. examining object files. I have started a similar development
  62. as yours a few weeks ago, but I had no time to continue it.
  63. So may be I can help you continuing the development of OBJSCN.
  64. The reference document I use is the Microsoft MS-DOS Programmer's
  65. Reference (Document no. 8411-310-02, part no. 036-014-012) which
  66. includes the description of Intel Object Module Format as used
  67. by the Microsoft linker.
  68.  
  69. Below is additional code to handle comment records class used
  70. by the linker. I have included support for the dynamic link
  71. records used by the DOS 4 / Windows linker (was documented
  72. in the material from the Microsoft Windows developer's conference).
  73.  
  74. I would like to include code for the new records type used by
  75. Microsoft C 4.0 (type B0 hex), but have no doc on it. These
  76. records define global data, including data size definitions,
  77. but I am not sure of the format.
  78.  
  79. Sorry for my english (I am swiss). I hope this is helpful
  80. to you. Regards.
  81.                          Daniel Cerutti.
  82.  
  83.                          Compuserve: 76267,426 
  84.                          BIX: dcerutti
  85.