>From microsoft docs on the PE format [1], which I'm guessing is where
that description came from, it describes the Import Directory Table with:
> The import directory table contains address information that is used
> to resolve fixup references to the entry points within a DLL image.
> The import directory table consists of an array of import directory
> entries, one entry for each DLL to which the image refers.
I think one could imply from that that the number of entries in the
Directory Table defines the number of DLL Import Lookup Tables? If
that's the case, then the Import_Lookup_Table should have
dfdl:occursCountKind="expression" and reference the number of Directory
Table Entires, e.g.:
<xs:elementref="Lookup_Table_Entry" maxOccurs="unbounded"
dfdl:occursCountKind="expression"
dfdl:occursCount="{ fn:count(../path/to/Directory_Table/Entries) }" />
- Steve
[1]
https://docs.microsoft.com/en-us/windows/desktop/debug/pe-format#import-lookup-table
On 3/3/19 3:48 PM, Costello, Roger L. wrote:
> To elaborate on my last message, the EXE specification says this:
>
> All image files that import symbols, including virtually all executable (EXE)
> files, have an .idata section. A typical file layout for the import
> information follows:
>
> Directory Table
>
> Null Directory Entry
>
> DLL1 Import Lookup Table
>
> Null
>
> DLL2 Import Lookup Table
>
> Null
>
> DLL3 Import Lookup Table
>
> Null
>
> Hint-Name Table
>
> Note the use of the word "typical." Apparently my EXE is not typical as it
> has 6 Import Lookup Tables.
>
> /Roger
>
> -----Original Message-----
> From: Costello, Roger L. <[email protected]>
> Sent: Sunday, March 3, 2019 3:17 PM
> To: [email protected]
> Subject: Re: Need help informing Daffodil that we're finished with this field
> and it's time to build the next field
>
> Hi Steve,
>
> The EXE specification is silent on the number of occurrences of the
> Import_Lookup_Table. All I know is that once we see the first Hint_Name_Table
> entry (a 2-byte address, followed by a null-terminated name, followed by an
> optional null) then we know that there are no more Import_Lookup_Tables. Is
> there a way to express (for Import_Lookup_Table):
>
> There are no more occurrences
> once we encounter a 2-byte
> address, followed by a null-terminated
> string, followed by an optional
> null.
>
> Is it possible to express that?
>
> /Roger
>
> -----Original Message-----
> From: Steve Lawrence <[email protected]>
> Sent: Sunday, March 3, 2019 11:25 AM
> To: [email protected]; Costello, Roger L. <[email protected]>
> Subject: [EXT] Re: Need help informing Daffodil that we're finished with this
> field and it's time to build the next field
>
> I think we need more information, specifically how do you know what is the
> last Import_Lookup_Table?
>
> Within an Import_Lookup_Table you say that the Lookup_Table_Entry ends with
> the last entry is all nulls, but that doesn't tell us where the last
> Import_Lookup_Table is. Is it when there's a special value of a
> Lookup_Table_Entry? Or maybe when the Import_Lookup_table has a no
> Lookup_Table_Entires and just has the terminating Null? Something else?
>
> You'll likely need to add a discriminator somewhere, but we'd need more
> information to know what that discriminator should be.
>
> - Steve
>
> On 3/3/19 7:55 AM, Costello, Roger L. wrote:
>> Hello DFDL community,
>>
>> In the Windows EXE file format there is one or more
>> Import_Lookup_Tables followed by a Hint_Name_Table. I am struggling
>> with how to inform Daffodil, "Hey Daffodil, the input is finished with
>> the Import_Lookup_Tables, now it's time to build the Hint_Name_Table."
>> I am hoping you can show me how to inform Daffodil of this.
>>
>> Each Import_Lookup_Table consists of one of more 32-bit fields,
>> terminated by a 32-bit field containing all nulls.
>>
>> The Hint_Name_Table consists of one of more entries; each entry
>> consists of a 2-byte address, followed by a null-terminated name,
>> followed by an optional null (to align to a 2-byte boundary).
>>
>> Here is a graphic that illustrates the Import_Lookup_Tables followed
>> by the
>> Hint_Name_Table:
>>
>> Here is the relevant portion of my DFDL schema:
>>
>> <xs:elementname="idata_Section">
>> <xs:complexType>
>> <xs:sequence>>
>> <xs:elementref="Import_Lookup_Table"
>> maxOccurs="unbounded"/>
>> <xs:elementref="Hint_Name_Table"/>
>> </xs:sequence>
>> </xs:complexType>
>> </xs:element>
>>
>> <xs:elementname="Import_Lookup_Table">
>> <xs:complexType>
>> <xs:sequence>
>> <xs:elementref="Lookup_Table_Entry"
>> maxOccurs="unbounded"/>
>> <xs:elementname="Null_Lookup_Table_Entry"
>> type="xs:hexBinary"
>> dfdl:lengthKind="explicit"
>> dfdl:length="4"
>> dfdl:lengthUnits="bytes"> <xs:annotation>
>> <xs:appinfosource="http://www.ogf.org/dfdl/";>
>> <dfdl:assert>
>> { . eq xs:hexBinary("00000000") }
>> </dfdl:assert> </xs:appinfo> </xs:annotation> </xs:element>
>> </xs:sequence> </xs:complexType> </xs:element>
>>
>> How do I inform Daffodil that the input has finished with the
>> Import_Lookup_Tables?
>>
>> /Roger
>>
>
