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 >
