On Fri, 2009-12-11 at 18:12 +0100, Danny Backx wrote:
> On Fri, 2009-12-11 at 17:48 +0100, Danny Backx wrote:
> > One of my ideas is that the mere number of sections of some type (CODE,
> > LOAD, DATA ?) might be a differentiator. This is in line with your
> > original assessment that .edata and .idata have to be absorbed
> > into .data or so.
>
> A couple of additional tests I just did show that with less sections,
> the DLLs can be loaded with LoadLibrary, but the export mechanism
> doesn't work.
>
> Original output of testapi :
> Started processing DLL(lib1.dll)
> lib1.dll doesn't know about open
> lib1.dll implements XmlPrologStateInitExternalEntity
> (0x01821760)
> LoadLibrary(lib2.dll) : cannot load DLL -> error 193
>
> Output of my latest test :
> Started processing DLL(lib1.dll)
> lib1.dll doesn't know about open
> lib1.dll doesn't know about XmlPrologStateInitExternalEntity
> Started processing DLL(lib2.dll)
> lib2.dll doesn't know about open
> lib2.dll doesn't know about XmlPrologStateInitExternalEntity
This is because the export and import tables were there but the pointers
to them were NULL :
The Data Directory
Entry 0 00000000 00000000 Export Directory [.edata (or where ever we
found it)]
Entry 1 00000000 00000000 Import Directory [parts of .idata]
I'm adding code to peXXigen.c to fix that.
Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
