Load 32-bit DLL library in 64-bit application

Question

Is there a way to load a 32-bit DLL library (something with the same usage as LoadLibrary) I would like to use that function along with GetProcAddress.

I looked at WOW, but it does not seem to offer the functionality. The functionality should exist, since tools like DependencyWalker are able to read the symbols of a 32-bit DLL even though its 64-bit.

Granlund

This is answered here: #128945 . John Knoeller's answer below is also correct. – Cutpurse

@John B. Lambe The title of this post is clearer than the one you linked for those who're searching the exe-call-dll thing. – Giveaway

Answer 1

You can only load a 32bit DLL into a 64 bit process when you are loading the dll as a datafile. You can't execute the code. (http://support.microsoft.com/kb/282423)

Microsoft recommends that you use interprocess COM to use 32 bit code with a 64 bit application. Here's an article explaining the process.

Barabarabarabas

Updated link for the article: blog.mattmags.com/2007/06/30/… See also #128945 – Futuristic

Answer 2

If all you're wanting to do is get resources from it, you can load as a datafile:

LoadLibraryEx(exeName, NULL, LOAD_LIBRARY_AS_DATAFILE);

Then call FindResource as normal.

Twinberry

LOAD_LIBRARY_AS_DATAFILE is Const LOAD_LIBRARY_AS_DATAFILE = $00000002; and free also the handle: FreeLibrary(LibHandle64); – Stall

Answer 3

There's a difference between reading a 32 bit executable and executing code within a 32 bit executable. I don't believe that windows offers any functionality to do that.

The only way you're likely to be able to do that is to create a 32 bit process that loads the dll and then do interprocess communication to pass the results between the two processes.

Higley

Answer 4

In theory, yes. I have implemented a way. The CPU allows it, the OS isn't directly but there's a workaround.

It is based on jumping around a long mode compatibility segment. In x64 there are "64-bit" segments which execute 64-bit code and "compatibility" segments that execute 32-bit code. While the GDT structure that contains that is only accessible from kernel mode, in Windows there's a preloaded 0x23 segment which can be jumped to if you know the way.

You also have to patch the Import Table but not with the normal GetProcAddress etc since this function will return 64-bit pointers (since you are running a x64 app) while you need to patch a 32-bit loaded library.

The code here demonstrates all that theory. My Code Project article explains it in detail and my generic Intel Assembly Manual explains the x64 internals. In the code in the above link I am creating a 32 bit DLL and loading it into the x64 process.

In practise, it doesnt work yet with win32 Dlls and even if it ever works I wouldn't use in production code. I am still working in it.

However x86 dlls are now dead. When I originally created my audio sequencer, for example, there were plenty of x86-only plugins where now almost everyhing ships (perhaps exclusively) as x64.

It's just for experimenting nowadays.

Automate