gwyn@smoke.BRL.MIL (Doug Gwyn) (09/28/89)
In article <8909261147.aa24830@SMOKE.BRL.MIL> MMPR004@ECNCDC.BITNET (Scott Hutinger) writes: >I thought I read that version 1 OMF and version 2 OMF files could be mixed. So did I (assuming the tools all understand OMF 2). I have my own questions about the description of the OMF segment header as described for OMF Version 2.1 in the APDA draft of the GS/OS Reference, Vol. 2, Appendix B. I would appreciate some definitive answers, so I can complete some software that I intend to release to the public domain. (1) "BYTECNT" in an OMF file appears to be measured in 512-byte blocks, not in bytes as the documentation says. Is this truly an error in the documentation? (2) The first "undefined" byte in the header is not always 0 in OMF Version 1 files produced by Orca/C (and perhaps APW C). What does it mean? It seems like the "KIND" word is always 0 when this occurs. The DUMPOBJ utility does NOT interpret the KIND as being 0 in such a case, which is why I suspect the kind is really encoded in the so-called "undefined" byte. (3) Both a "VERSION" and a "REVISION" are documented for describing the "compatible OMF version", and their explanation is not clear. However, only one of these is shown in Figure B-2 and only one seems to be present in OMF version 1 files. Is this a documentation error? What do they really mean? If "REVISION" is present, where? (4) The "tempORG" field is shown as immediately following "DISPDATA", but Figure B-2 gives its offset incorrectly and calls it "tempOrg". (5) The text for "DISPNAME" says it's currently 44, but it must be 48 if "tempORG" is really present. (6) Table B-2 says the attributes bits are 10-15 but then shows bits 8-15.