Yury Sidorov wrote: > From: "Andrew Haines" <[EMAIL PROTECTED]> >> Yury Sidorov wrote: >>> >>> Actually import by ordinal is implemented in works. Look at line 2416 of >>> ogcoff.pas >>> When AOrdNr < 0 it indicates that import is by name, but ordinal number >>> is specified as hint. Whan AOrdNr > 0 then import by ordinal only. >>> >> >> Okay yes I see that, but that is for the import lookup table not the >> import address table, the import address table is the same format as the >> import lookup table. >> >> Here is the behavior I observed: >> >> I import a function by index >> >> function SomeFunction: stdcall; external 'xboxkrnl.exe' index '1'; >> >> when it is compiled the start of the .idata section looks like this: >> >> ImportLookupTablePtr >> DateTimeStamp >> Junk >> PtrToLibName >> ImportAddressTablePtr >> >> The Import Lookup Table is written correctly with the ordinal name as >> expected. When I look at the Import Address Table, the entries are *not >> the same* as the lookup table, as they should be, but instead *point* to >> an address that contains the ordinal(not or'ed), when it should contain >> $80000000 or'ed against the import ordinal. >> >> >>> From the MS docs talking about the Import Address Table: >> >> "Import Address Table RVA(Thunk Table): The RVA of the import address >> table. The contents of this table are identical to the contents of the >> lookup table until the image is bound." >> >> So even if my confusing explanation doesn't make sense, the Address >> Table should mirror the Lookup Table which it doesn't. >> >> It looks like maybe you are writing a Hint/Name table entry for an >> ordinal which is only done when importing by name. > > Yes. You are right. Import Address Table should contain the same data as > Import Lookup Table. Currently it contains different data when importing > by ordinal. > It should be fixed, but it currently this bug has no effect on > win32/64/CE. EXEs with ordinal imports are loaded properly. > Does it afeect xbox? >
Yes. The xbox exe loader does not know it is looking at a IAT in the .idata section, but thinks it is looking at a different IAT not in the idata (which neither gcc nor fpc create, only the MS compiler seems to make it) section which does not have a corresponding Lookup table. I suspect the windows exe loader is checking the Lookup Table when it finds invalid data in the IAT. Andrew _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
