Ok so you're wanting to load in some win32 dll's into a win64 process. 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
