1

I'm aware that it's not possible to load a 32-bit DLL into a 64-bit process. The DLL in question is a ODBC driver which is no longer supported (although it works fine) and no 64-bit version of it exists. I don't have access to the source code either.

There doesn't seem to be an off-the-shelf way of "thunking" between the two architectures - the only option I can think of is to write a 32-bit COM object and get it to wrap the 32-bit DLL, and then also write a 64-bit DLL which exposes the same API the 32-bit DLL exposes and then bridge the gap by serializing the parameters to the API call and utilising DCOM's data marshalling functionality to get across the 32-bit / 64-bit boundary. This is a pretty tedious approach though and it could be quite slow if the interface is "chatty".

So what I'm wondering is if there are any other ways of solving this problem?

user131837
  • 19
  • 1
  • 2
  • 2
    or a second background process that loads the 32 bit dll and communicates with the 64 bit process – ratchet freak May 19 '14 at 17:04
  • Do you have access to the code for the 64-bit application? Can you just build that one as 32-bit? – Gray May 19 '14 at 18:22
  • 2
    This question already has an answer on SO: http://stackoverflow.com/questions/128445/calling-32bit-code-from-64bit-process – Doc Brown May 20 '14 at 07:58
  • Hi, thanks for the replies. I don't have access to the 64-bit app's source code either. The main scenario I'm dealing with by the way is 64-bit SQL Server trying to setup a linked server (via sp_addlinkedserver) to another database via it's 32-bit ODBC driver. It's a shame that all that plumbing code has to be written by hand :( – user131837 May 20 '14 at 10:38

0 Answers0