I have a 32-bit dll that I have gotten from a third party. They have no 64 bit version. I wish to load this dll into 64 bit python. To do this, I need a 64 bit dll. Is there a tool to convert a 32 bit dll to a 64 bit dll or is this impossible? If it impossible then I must use 32 bit python I guess.
Only the vendor can do this, unless you get access to the DLL's source code. It must be recompiled for 64 bit.
I guess you'll have to use 32-bit python...
32 and 64bit DLLS have different ABIs and calling conventions. You just can't load a 32bit DLL into a 64bit process or the other way around.
As mentioned in the comments, you have to recompile from source.
You can't create a 64-bit DLL from 32-bit one without the source code.
But you can create an adapter as a native 32-bit application that loads the 32-bit DLL and provides access to it's functions via some kind of inter-process communications (e.g. named pipes)
Of course, that's may be senseless in some cases and you may prefer to use 32-bit python.
So it depends.
Related
Can functions in a 32 bit dll be called from a 64 bit dll using the LoadLibrary function?
Technically, it happens all the time when 32-bit processes are running on a 64-bit Windows. There's 64-bit ntdll.dll, which loads Wow64 layer DLLs and 32-bit ntdll.dll.
So it is hypothetically possible. If OS does this, you also should be able to do this.
In practice this may be not feasible without OS internals knowledge. Use a 32-bit process for that 32-bit DLL, and some sort of inter-process communication.
I am going to make a device driver for 64 bit platform (i.e. Win7) and I would also like to expose device APIs in DLLs which could be distributed to users writing their applications.
The question is, how could I build such DLLs both for 32bit and 64bit applications?
The problem here is actually only about 32 bit one.
could I just write DLL and compile it in 32 as well as 64bit?
Or do I really need some IPC to wrap 64bit dll so that 32bit application can indirectly invoke device driver?
The translation between 32 and 64 bits should take place at the existing user-kernel layer. Your DLLs will use IOCTL commands to communicate with the driver, and the 32-bit DLL will have to use 64-bit IOCTL structures when the driver is 64-bit.
There's no need to add a second IPC layer.
I'm thinking like Apple did with their universal binaries containing both x86 and ppc code
No. The IMAGE_FILE_HEADER.Machine field determines whether a DLL is x86 or x64. One field cannot hold two different values simultaneously, and there's only one IMAGE_FILE_HEADER in a DLL.
That said, a pure .Net DLL contains IL instructions, and they can be compiled to either 32 bits or 64 bits.
You can build the dll as 32Bit and it can work in both 64 and 32 environment, but it will be 32 bit dll
I'm going to redistribute gsdll32.dll, main library of GhostScript. There are two versions available for download, 32 and 64 bit. Will the first one work on 64-bit systems, or I need package two versions separately?
It depends on how the .exe is built. If you build a .exe for 32 bit, you need the 32 bit dll. It will work on 32 and 64 bit systems.
I ask because I noticed that many 64 bit EXEs link against what appear to be 32-bit DLLs.
For example, my 64 bit MFC app links against user32.dll, urlmon.dll, wininet.dll - all of which are 32 bit DLLs that reside in windows\system32.
So is this some MS specific wizardry that applies to these DLLs, or is there backward compatability, as it were, for 64 bit EXEs that need to use legacy 32 bit DLLs?
You cannot link 64-bit EXEs to 32-bit DLLs or vice versa. On a 64-bit Windows OS, the DLLs in Windows\System32 are actually 64-bit DLLs. The 32-bit versions are in Windows\SysWow64.
Call 32 from 64, Sure It can. (In windows this is called WOW wich means Windows on Windows). But, viceversa It doesn't work.
Here you have the explanation of how:
http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/
Hope it serves.
The latest version of Dependency Walker (found here: http://www.dependencywalker.com/) fixes this issue. It finds the correct DLLs, and avoids the inaccurate errors.
(I'm late to the party, but google still found this question when I had a similar problem.)