Visual studio compiles 32 bit application but links to 64 bit windows libraries. How to use 32 bit libraries instead?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(48, 83%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAT%3C/text%3E%3C/svg%3E)
Albertine, Thomas
1
Reputation point
I'm using visual studio 2013, and trying to build a 32 bit application that will run on older 32 bit lab machines running windows 7, and eventually newer 64 bit lab machines that will be running 64 bit windows 10. The machine I have to develop with right now is a 64 bit windows 7.
I've cloned our repo and I built the project without issue, but when I try to run it, I get an error about a library or it's dependencies not being 32 bit windows applications. I've determined that all of our C# projects are configured to run as Win32, and all the C++ projects are configured to run as x86, but this does not resolve the error.
I tried opening up the executable using a dependency walker program. I couldn't execute it, so I couldn't see DLLs that get loaded during normal execution, including the ones we produce, but I did notice that our application was 32 bit, but all the Windows DLLs are 64 bit, which seems like it would be a problem.
I opened our DLLs as well and ran into the same situation. The DLL was built as 32 bit, but all the windows libraries were 64 bit.
Am I correct in my understanding that this is a problem, and how can I change the solution to use 32 bit windows libraries?
Windows for business | Windows Client for IT Pros | User experience | Other
Developer technologies | C++
Developer technologies | C++
A high-level, general-purpose programming language, created as an extension of the C programming language, that has object-oriented, generic, and functional features in addition to facilities for low-level memory manipulation.
Developer technologies | C#
Developer technologies | C#
An object-oriented and type-safe programming language that has its roots in the C family of languages and includes support for component-oriented programming.
{count} votes
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(268.8, 45%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EC%3C/text%3E%3C/svg%3E)
cheong00 3,486 Reputation points Volunteer Moderator2021-06-16T03:34:25.313+00:00 The situation don't make sense to me.
When Windows load EXE with file header "machine type" set to "014C"(x86) instead of "8664"(x64), the file system redirector should map "%systemroot%/SysWOW64" to "%systemroot%/System32" for that process, so all Windows system libraries it loads should be pointed to 32-bit version.
You can check the file header with "dumpbin /headers <filename.exe>" inside "Developer Command Prompt for VS 20XX".
IIs it really loading 64-bit version of Windows DLLs, or just that you see the paths are something like "C:\Windows\System32"? If so than it is pretty normal. If that is 64-bit then things got interesting because the 32-bit loader do not know how to handle 64-bit binaries. :O
-
cheong00 3,486 Reputation points Volunteer Moderator
2021-06-16T03:39:41.07+00:00 If you check the DLL handles list with Process Explorer, you should only see the following 64-bit DLL handles for 32-bit process.
- apisetschema.dll
- C_<codpage>.nls
- locale.nls
- ntdll.dll
- wow64.dll
- wow64cpu.dll
- wow64win.dll
These DLLs are used by the loader to setup WOW64 translation layer. Other DLLs of Windows should come from SysWOW64 folder.
-
RLWA32 51,536 Reputation points2021-06-16T10:22:30.673+00:00 Additionally, a 32-bit build of an unmanaged C++ project cannot link successfully with the 64-bit Windows import libraries from the Windows SDK.
-
Lex Li 6,037 Reputation points2021-06-16T14:50:27.617+00:00 Try to create a few hello world apps to test, so that you can easily find out what is wrong. Don't let miserable things in a relatively big repo mislead you.
-
Albertine, Thomas 1 Reputation point
2021-06-17T00:46:39.82+00:00 Ok, so I found out that the reason my dependency checker was pulling the 64 bit libraries when I scanned the app was because I was trying to profile the app using the 64 bit version of the dependency checker. When I use the 32 bit version, it pulls the correct ones. So my original problem was just me being dumb.
I have checked that all the projects are configured to build 32 bit. My current theory is that I only have the 64 bit version of a library we got from a vendor installed, so it's trying to load that since the 32 bit version isn't there. Or something like that anyway.
Sign in to comment
Sign in to answer