Rahul Singh
Rahul Singh

Reputation: 87

Can I load a dll into shared memory?

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?

Upvotes: 3

Views: 285

Answers (2)

marcinj
marcinj

Reputation: 49986

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.

Upvotes: 3

Mats Petersson
Mats Petersson

Reputation: 129374

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).

Upvotes: 5

Related Questions