Can I load a dll into shared memory?

Question

I have access a 32 bit dll from a 64 bit application. For this I am using Shared Memory IPC and I have done something like this

TCHAR szName[]=TEXT(Path of DLL on local machine); 
TCHAR szMsg[]=TEXT("abc");

HANDLE file = CreateFile(szName,                
                       GENERIC_READ,          
                       0,                      
                       NULL,                   
                       CREATE_NEW,             
                       FILE_ATTRIBUTE_NORMAL,  
                       NULL);

Is it the correct approach to share a dll over an IPC? Can I access the functions defined inside DLL at the reader interface?

Sorry, this makes no sense unless you elaborate a lot farther. Forget about 32b vs. 64b for a second. How would you `share a dll over an IPC` and `access the functions defined inside DLL at the reader interface` if both ends were the same bitness, say, 32b? Maybe you mean http://stackoverflow.com/questions/128445/calling-32bit-code-from-64bit-process. — dxiv, Nov 25 '15 at 08:28

score 5 · Answer 1 · answered Nov 25 '15 at 07:47

It is, by definition, not possible to call a 32-bit function from 64-bit code. The processor behaves differently in 32-bit and 64-bit mode. The OS can do different things for 32-bit and 64-bit applications by setting the code-segment selector to 32- and 64-bit mode respectively, but that is a big switch for the entire application.

32-bit calls have a different calling convention to 64-bit code. (64-bit mode uses registers for the first 5-6 arguments for all calls, 32-bit mode only 3 arguments, and not for all functions). General register usage (which registers are used for what) is different, so registers that need to be preserved in 32-bit are not needing that in 64-bit bit, and so on.
32-bit operations clear the upper part of 64-bit registers, whether they want to or not. So just setting eax to 5 will alter the upper 64-bits of eax, which the 32-bit code has no knowledge even existed.
Pointers in 64-bit mode are allocated in the full 64-bit range [well, 47-bits, but that's still 15 bits more than 32], so you won't be able to pass any pointers to the called code, even if not a single of the other problems existed.
push and pop instructions with register operand are now 64-bit (regardless of whether you want that or not), so the 32-bit code will save registers thinking they take up 4 bytes of stack, and they will take up 8, meaning any offset from stack pointer calculation will be wrong inside the called function - including the common sequence: push ebp and mov ebp, esp, the value of esp is now wrong.
Some instructions are no longer available or are only available in their alternative form. In particular, byte values 0x40-0x4f is "prefix" for 64-bit instructions, rather than the instructions they used to be.
Any calls from your "imported code" will be seen as 64-bit, so OS-calls, C library calls, etc, won't work correctly.

Of course, you can READ the file, transcribe it into 64-bit mode, but that would require a huge amount of work in coming up with a translator that understands the code and can translate it it (since you'd need to know what is actual code, and what is for example jump-tables for switch statements or text-strings embedded in the code-segment, which shouldn't be translated, at least not in the same way).

Most likely it's 10 times easier to recompile the code as 64-bit. Or recompile your 64-bit app as 32-bit (which is almost certainly the EASIEST option).

score 3 · Answer 2 · edited Nov 25 '15 at 21:42

If you cannot recompile this dll as 64bit then you your only choice is indeed IPC, but not in a way you describe it. You would have to write additional application, lets name it dllwrapper32.exe which would load your 32bit dll and expose its interface using some IPC method. Your 64bit application would use this IPC method to communicate with 32bit dll over dllwrapper32.exe process.

You could also write 64bit dll wrapper which would do the comunication between 64bit process and dllwrapper32.exe. So to visualize the basic idea:

                      ^-- loads ----> [32 bit dll]
                     /
           [dllwrapper32.exe] <---- IPC -----> [64 bit process]

now with 64 bit wrapper dll:

                      ^-- loads ----> [32 bit dll]
                     /
           [dllwrapper32.exe] <---- IPC -----> [64 bit wrapper dll]
                                                          /\
                             [64 bit process] - loads ----'

IPC can be aything you want:

Clipboard
COM
Data Copy
DDE
File Mapping
Mailslots
Pipes
RPC Windows
Sockets

I suppose COM would be recomended.

So in the end - a lot of work.

Can pipe be used here i.e. for communication between two separate process, without any common ancestory? — Rahul Singh, Nov 26 '15 at 10:33
I suppose yes, the choice of IPC method should depend on how your DLL api looks like, if you want to access single api function then you can use more low level IPC aproach, if you have lots of functions to expose then COM might be better. — marcinj, Nov 26 '15 at 11:09

Can I load a dll into shared memory?

2 Answers2