Hello all

Sorry for X-posting, If there's a more appropiate group, please f'up to it.

I've looked a the binary source of several .net modules both with a hex
editor and with a parser I've written.

There are several things I've noticed and/or don't quite understand with
how the metadata is layed out in the Portable Executable File:

1. is there an updated specifaction (or draft), newer than
http://msdn.microsoft.com/netframewo...gramming/clr/?
I'll refer to the documents on this webpage in the following

2. in "CLI Partition II - Metadata Definition and Semantics" part 23

a) I've found dlls in which the the "#~" stream was named "#-" (0x23
0x2d instead of 0x23 0x7e). This seem to be in violation of the spec.
The dlls were produced by VS.Net 2002.

b) within the #~ stream (23.2.6), the spec says that "MinorVersion"
should always be 0 and the second "reserved" be 1.
I've found that "MinorVersion" seems to be always 1 when using the
framework 2/VS 2005 beta version, is this correct?.
Is there a specifaction on how VS 2005 generates these values?

Also, the second reserved is not always 1. What's the relevance of this
value?

3. In section 23.2.3 the spec says that indeces to the "#strings" heap
should point to an valid null terminated string. Does that mean that if
i have a string "testtest", which is indexed at offset 1, i can index a
second string "test" just by pointing at offset 5? (of course you'd have
to take unicode in account, but in principle, can you index substrings?)

Thanks
Ben

> a) I've found dlls in which the the "#~" stream was named "#-" (0x23 0x2d
> instead of 0x23 0x7e). This seem to be in violation of the spec. The dlls
> were produced by VS.Net 2002.

The #~ stream is a optimized stream. #- is unoptimized and contains extra
lookup tables. Page 181 of partition II says:

Implementation Specific (Microsoft Only)
Some compilers store metadata in a #- stream, which holds an uncompressed,
or non-optimized, representation of metadata tables; this includes extra
metadata "pointer" tables. Such PE files do not form part of this ECMA
standard

> b) within the #~ stream (23.2.6), the spec says that "MinorVersion"
> should always be 0 and the second "reserved" be 1.
> I've found that "MinorVersion" seems to be always 1 when using the
> framework 2/VS 2005 beta version, is this correct?.
> Is there a specifaction on how VS 2005 generates these values?

The new ECMA specs are not available AFAIK.

> 3. In section 23.2.3 the spec says that indeces to the "#strings" heap
> should point to an valid null terminated string. Does that mean that if i
> have a string "testtest", which is indexed at offset 1, i can index a
> second string "test" just by pointing at offset 5? (of course you'd have
> to take unicode in account, but in principle, can you index substrings?)

I've done so, and don't see how this would be a problem...

-mike
MVP

Michael Giagnocavo [MVP] wrote:
>>a) I've found dlls in which the the "#~" stream was named "#-" (0x23 0x2d
>>instead of 0x23 0x7e). This seem to be in violation of the spec. The dlls
>>were produced by VS.Net 2002.
>
>
> The #~ stream is a optimized stream. #- is unoptimized and contains extra
> lookup tables. Page 181 of partition II says:

which doc are you refering to?
the documents I've got from
http://msdn.microsoft.com/netframework/programming/clr/ which are "Final
Draft October 2003" do not mention this. (No page no. 181, search for
"#-" doesn't find a match)
You can't even google for "#-"...

>
>>3. In section 23.2.3 the spec says that indeces to the "#strings" heap
>>should point to an valid null terminated string. Does that mean that if i
>>have a string "testtest", which is indexed at offset 1, i can index a
>>second string "test" just by pointing at offset 5? (of course you'd have
>>to take unicode in account, but in principle, can you index substrings?)
>
>
> I've done so, and don't see how this would be a problem...

Thanks
Ben

>>
>> The #~ stream is a optimized stream. #- is unoptimized and contains
>> extra lookup tables. Page 181 of partition II says:
>
>
> which doc are you refering to?
> the documents I've got from
> http://msdn.microsoft.com/netframework/programming/clr/ which are "Final
> Draft October 2003" do not mention this. (No page no. 181, search for
> "#-" doesn't find a match)
> You can't even google for "#-"...
>

Hi,

the .NET SDK from Microsoft provides anotated versions of these specs.
For me (and my v1.1 SDK) they live at:

\Program Files\Microsoft.NET\SDK\v1.1\Tool Developers Guide\docs\*.doc

They contain inline notes about Microsoft's implementation of the ECMA
standard (like the p181 comment mentioned above).

Mike

> the .NET SDK from Microsoft provides anotated versions of these specs.
> For me (and my v1.1 SDK) they live at:
>
> \Program Files\Microsoft.NET\SDK\v1.1\Tool Developers Guide\docs\*.doc
>
> They contain inline notes about Microsoft's implementation of the ECMA
> standard (like the p181 comment mentioned above).


thanks mike,

there's also an updated version coming with the framework 2.0 beta sdk

Ben