Walter, just a quick question.

I was experimenting with a OMF object file dumper that I'm programming, and then comparing the results with the OMF spec. But there's a record that I can't managed to 'decipher' (so to speak).

Specifically, I'm having issues with the Comment Record (0x88) with the class 0x9d, that according to the spec represents the Memory Model. This record is almost always the second one to appear in the object files, and its contents, according to the spec are:

     "The byte string consists of from one to three ASCII
      characters and indicates the following:"

      0, 1, 2, or 3    - 8086, 80186, 80286, or 80386
                         instructions generated,
                         respectively

      O                - Optimization performed on code

      s, m, c, l, or h - Small, medium, compact, large, or
                         huge model

      A, B, C, D       - 68000, 68010, 68020, or 68030
                         instructions generated, respectively

However, when I extract the aforementioned byte string, I get '7nO'. Now, I suppose that the 'O' means that the code is optimized, but what about '7' and 'n'. They aren't specified on the spec and don't know what they mean. Can you shed some light on this?

I know that you have a tool to read this kind of information (objdump or something like that), but I would like to understand a little bit what's going on. It's the object file I'm analyzing corrupt? Is there something different between the spec and how the OMF files that DMD generates?

Thanks.

On 2/11/2012 3:42 PM, Yao G?mez wrote:
> Walter, just a quick question.
>
> I was experimenting with a OMF object file dumper that I'm programming, and then comparing the results with the OMF spec. But there's a record that I can't managed to 'decipher' (so to speak).
>
> Specifically, I'm having issues with the Comment Record (0x88) with the class 0x9d, that according to the spec represents the Memory Model. This record is almost always the second one to appear in the object files, and its contents, according to the spec are:
>
>     "The byte string consists of from one to three ASCII
>      characters and indicates the following:"
>
>      0, 1, 2, or 3    - 8086, 80186, 80286, or 80386
>                         instructions generated,
>                         respectively
>
>      O                - Optimization performed on code
>
>      s, m, c, l, or h - Small, medium, compact, large, or
>                         huge model
>
>      A, B, C, D       - 68000, 68010, 68020, or 68030
>                         instructions generated, respectively
>
> However, when I extract the aforementioned byte string, I get '7nO'. Now, I suppose that the 'O' means that the code is optimized, but what about '7' and 'n'. They aren't specified on the spec and don't know what they mean. Can you shed some light on this?
>
> I know that you have a tool to read this kind of information (objdump or something like that), but I would like to understand a little bit what's going on. It's the object file I'm analyzing corrupt? Is there something different between the spec and how the OMF files that DMD generates?
>

The 7 is for the 786 (!), just the next CPU. 'n' was originally the 'Windows NT' memory model, which was not in the original OMF spec.

On Tue, 14 Feb 2012 16:36:56 -0600, Walter Bright <walter at digitalmars.com> wrote:
>
> The 7 is for the 786 (!), just the next CPU. 'n' was originally the 'Windows NT' memory model, which was not in the original OMF spec.

Thanks Walter! Just for the record... is this purely informational? or the linker uses that info for something when blitting the final executable?

On 2/14/2012 5:10 PM, Yao G?mez wrote:
> On Tue, 14 Feb 2012 16:36:56 -0600, Walter Bright <walter at digitalmars.com> wrote:
>>
>> The 7 is for the 786 (!), just the next CPU. 'n' was originally the 'Windows NT' memory model, which was not in the original OMF spec.
>
> Thanks Walter! Just for the record... is this purely informational? or the linker uses that info for something when blitting the final executable?
>

The linker uses it to give an error if you try mixing up code compiled for different memory models.