In the included metadata file, we have a total of 16439 rows that compute potential ResolutionScope:
1 Module
366 ModuleRef
5 AssemblyRef
16067 TypeRef
This ResolutionScope has two bits reserved for the table assignment, which should leave a total of 16383 index rows in ResolutionSope in order to fit into the 2 BYTE configuration.
I've verified with ILSpy that these are the right counts and that my alignment "works" with a 2 BYTE ResolutionScope length, but I have no idea why its being encoded 2 bytes long based on the above counts. Is this an issue with the file or my understanding of coded index?
Since the 16439 referents > 16383 possible 2 byte addressing possible, shouldn't the TYPE_REF[0] field length get bumped to 4 bytes?
I did get it wrong. The remaining non-reserved bits is a row number into the remove table, so it isn't a sumOf, but a maxOf each type making TypeRef's 16067 < 16383!
Hi, I've been tinkering with a Java based implementation of a WinMD parser and I ran into one snag which I'm not able to find a solution around.
The reference file I'm looking at is: (https://www.nuget.org/packages/Microsoft.Windows.SDK.Win32Metadata/) File version: 59.0.13-preview
According to the ECMA-335 Spec, and the CPP implementation (https://github.com/microsoft/cppwin32/blob/8a6b2507734dd9e9892059b5794f35109688fc20/cppwin32/winmd/impl/winmd_reader/database.h#L441), the
TypeRef
first column is a coded index to aResolutionScope
.In the included metadata file, we have a total of 16439 rows that compute potential ResolutionScope:
Module
ModuleRef
AssemblyRef
TypeRef
This ResolutionScope has two bits reserved for the table assignment, which should leave a total of 16383 index rows in ResolutionSope in order to fit into the 2 BYTE configuration.
I've verified with ILSpy that these are the right counts and that my alignment "works" with a 2 BYTE ResolutionScope length, but I have no idea why its being encoded 2 bytes long based on the above counts. Is this an issue with the file or my understanding of coded index?
Since the 16439 referents > 16383 possible 2 byte addressing possible, shouldn't the TYPE_REF[0] field length get bumped to 4 bytes?