On 24/01/17 11:08, David Marceau wrote: > Ok so you're wanting to load in some win32 dll's into a win64 process. What makes you think that?
AFAICT, the only issue here is that the DLL tries to (wrongly?) import DllMain. This occurs with the 64-bit builds of the DLL but not with the 32-bit builds. The faulty DLL is in mingw-w64-x86_64-gtkglext, which is 64-bit. I do not even have *any* 32-bit DLLs at all on that system. Cheers Antoine > There used to be a way to interact/interoperate win16 to win32 via > "thunking" api's. the thunking api's no longer seem to be valid from > win32 to win64. There are some discussions about using out-of-process > COM to communicate between win32 to win64. > The only thing I have seen that may be related is loading a win32 dll > directly from win64 may only be allowed in the scenario for getting data > and not for executing code..."Loading a DLL as a Data File or Image > Resource": > https://msdn.microsoft.com/en-us/library/ms684179(v=vs.85).aspx > LOAD_LIBRARY_AS_DATAFILE > LOAD_LIBRARY_AS_IMAGE_RESOURCE > > Possibly the intention here for loading legacy gtk strings, gtk icons, > other gui gtk resources from the win32 version gtk dll. > > It is clear that you may not execute win32 code from win64 apps. You > may only invoke an entire separate win32 process that may run win32 apps > and load win32 executeable dll's but they run entirely in a separate > process INACCESSIBLE FROM ANY WIN64 DLL/EXE. There ARE EXCEPTIONS...If > you write a service...if you write devices drivers. For your case, > these two exceptions may be considered if you use some clever > circumvention techniques, but they require unexpected amounts of effort. > > I have seen in win32...when you pass data structure pointers via local > in-process COM or out-of-process COM(to other processes) you can get > away with sending it as a LPVOID and recasting it on the other end with > the expected pointer to a structure type. Doing something like this was > possible with win32 <<-->> win16. I imagine it may be possible from > win32 <<-->>win64 but it's highly undocumented and the os/anti-virus > will probably complain unless you turn off ASLR when compiling/linking. > I've never done that because that implies throwing away recommended > security guidelines. I heard that internet explorer does use both win32 > code dlls and win64 code dlls. hmmm.... > http://www.w4rri0r.com/sequence-of-commands/exploit-windows-32-bit-and-64-bit-application.html > > > On 01/23/2017 11:54 AM, Antoine Martin wrote: >> On 23/01/17 22:31, David Macek wrote: >>>> On 23. 1. 2017 13:58, Antoine Martin wrote: >>>>> Hi, >>>>> >>>>> It seems that the 64-bit version of the gtkglext package is missing >>>>> something as we are unable to load one of the DLL it installs: >>>>> >>>>> pacman -S mingw-w64-x86_64-gtkglext >>>>> python -c 'from ctypes import >>>>> cdll;cdll.LoadLibrary("C:\\msys64\\mingw64\\bin\\libgdkglext-win32-1.0-0.dll")' >>>>> >>>>> fails with: >>>>> WindowsError: [Error 127] The specified procedure could not be found >>>>> >>>>> The 32-bit version does not have this problem. >>>>> ldd doesn't show anything missing, depends.exe does show some problems >>>>> with libgdk_pixbuf - but I'm not sure I trust this ancient tool. >>>>> (and gdk_pixbuf is there of course) >>> >>> Manual inspection showed that the DLL is trying to import `DllMain` from >>> libgdk_pixbuf-2.0-0.dll, which it does not export. The 32-bit version has >>> got no such import entry. >> A quick googling hits this: >> https://github.com/mirror/mingw-w64/blob/master/mingw-w64-crt/crt/dllmain.c >> >> So I guess that it might be enough to link against it? >> I just don't understand why the 64-bit version would need this >> explicitly when the 32-bit build does not. >> >>>>> Questions: >>>>> * what is the best way to check that a DLL is valid and has all its >>>>> required dependencies installed? (I use python here but surely there is >>>>> a better way?) >>> >>> I don't know any reliable general-purpose way. Seems like only ctypes and >>> depends find the issue. >>> >>>>> * can I trace the DLL loading to see where it is failing? >>> >>> You can try `ntldd`, `ldd`, `cygcheck`, `depends`, all with varying degrees >>> of success, YMMV. >>> >>>>> * since this problem does not affect the 32-bit version, it is fair to >>>>> assume that something is going wrong during building / linking - are >>>>> there any specific gotchas to look for? >>> >>> Sometimes an accident happens and there are bad packages (sometimes only on >>> one architecture), so it's good to ask if others have the same problem. I >>> can confirm this happens to me as well. If I run an appropriate command >>> outside MSYS2 (i.e. in plain cmd), I even get an error saying it's >>> `DllMain` that's missing. >>> >>> In conclusion, it seems some package(s) require(s) re-building. You should >>> probably open a ticket on <http://github.com/alexpux/mingw-packages>. >> Thanks. Done: >> https://github.com/Alexpux/MINGW-packages/issues/2121 >> >> As noted there, I've tried building from source but that didn't make any >> difference. >> >> Cheers >> Antoine >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Msys2-users mailing list >> Msys2-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/msys2-users >> > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Msys2-users mailing list > Msys2-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/msys2-users > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Msys2-users mailing list Msys2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/msys2-users
