I have a 32-bit dll which links against (my) binaries from System32 instead of SysWOW64. This dll is a C++ project part of an x86 Outlook add-in and it should link to some binaries in the system folder, but as I'm on a 64-bit system, I'd expect it to try and find them in SysWOW64, not System32.
I have tried copying the 32-bit version of those binaries in System32 and that works, but it's clearly not the solution and all kind of other errors spring from it.
Where can I change the location Visual Studio has for the x86 system folder?
A 32-bit app running under WOW64 sees a virtualised environment, not the real filesystem.
It only thinks it is linking with System32. What it sees as System32 is in reality SysWOW64.
In a similar way it has a virtualised view of the registry and other vital system resources.
This is because the purpose of WOW64 is to enable binary compatibility. Therefore the environment the application sees must look as if it is running on a 32bit operating system.
Related
I am using Visual Studio 2010 in x64-based processor.
I got error LoadLibrary(_T("xx.dll")) with 126.
I tried dependency Walker to find out all .dll and module, function dependencies. It shows everything is fine.
Actually old code was working fine in 32bit operating system and compiled. After I moved to 64bit operating system, There is an error.
I copied all the .dll libraries in same directory with .exe file.
Is there any conflict between compiled xx.dll in 32bit then after execute at 64bit?
Thank you so much for any suggestion and advice.
64bit applications can't load 32bit DLLs, WOW64 (windows 32bit emulation on 64bit) just works for spawning processes/executables, not what happens on runtime. Already answered multiple times on SO, like here.
You need to compile/get 64bit versions of your DLLs.
How do I know if the program I am writing in C++ will run properly in a 32-bit OS or not?
(without manually testing in one)
I am using Visual Studio and compiling in a 64-bit machine. Will that stop the program from working in other machines?
And what about the processor and Windows version? Will the binary be compatible with most Windows versions and processors, if the program just does a few simple things such as web requests and calculations, with a simple user interface?
My program doesn't have to be 64-bit. I would just like to create one binary that runs in most computers, like those I download every day on the Internet. How could I do that?
If you are building your code specifically for 64-bit Windows, you can't expect the binary to work on 32-bit Windows. That will require a separate build.
An executable compiled and linked for 64-bit will typically also require 64-bit libraries.
Use tools like the Dependency Walker to find out, if a given executable is refering to 32- or 64-bit libraries.
In Visual Studio, the "target platform" decides which CPU architecture you are targeting. It is perfectly feasible to create 64-bit executables on a 32-bit system, but you can't actually run them on such a machine.
You can do what's called cross-compiling i.e compiling on one machine for another. How to compile a 32-bit binary on a 64-bit linux machine with gcc/cmake This is what you're after if I read you correctly. There should be a Windows equivalent.
I am trying to test my static library that i used to build in win xp 32bit. So, I made a test application that utilizes the static lib to print out a code.
Now, i wanted to see its behavior on a 64 bit OS. How do i go about doing that?
Do i need to install vs2008 on that one and create my test application on it then port my static lib and build it there? Or is there a way where i can just port my existing application exe and static lib to a 64 bit machine?
Also is it true that on a 64 bit OS i need to have a 32bit app in order to run a static lib that was created in a 32bit environment?
The goal is to check to see if my static lib would work in a 64bit environment. Also, please note they will be installing this static lib on multiple computers so I do not expect any network access per se.
The one API that i am giving to them uses const char * as an input parameter since I use strings internally. Not sure if I need to create an optional parameter of __int64 and then convert that to a string internally as well.
Using VisualStudio, you can build 64-bit binaries on a 32-bit box. You just can't run them there. Whether it is a good idea to use a 32-bit machine as your build machine is a whole other story, but yes, it can be done.
So you build your 64-bit app on OLDCLUNKER32, which is a 32 bit box. Move those binaries over to NEWHOTNESS64 which is a 64 bit box, install any Visual Studio redistributable packages you might need, and run your app. You can run 32-bit code on a 64-bit box, but you can't mix 64-bit and 32-bit binaries in a single application. For example, your EXE and all DLLs must be the same, weither 64 or 32 bit.
Your clients don't need to install VisualStudio to run your app, right? Well, neither do you. Install the appropriate redistributable for your platform, and you should be able to run your app.
Write good unit tests, build them on 64-bit platform and execute. If some unit tests fail, you have a problem.
I have Credential manager implemented in VC++ which captures credentials during login process. It works well in XP/Vista/Windows 7 32 bit env. But is not working in 64 bit.
Any idea ?
Thanks in advance for any help
If you want your DLL to be loaded by a 64-bit process, your DLL has to be compiled for 64 bits.
If you want your DLL to be loaded by a 32-bit process, your DLL has to be compiled for 32 bits. This is true on both 64-bit Windows systems and 32-bit Windows systems.
John gave you a useful link, even though John's wording is wrong. An application (exe) which is built for 32 bits will run in 64 bit Windows, but it can only load 32-bit DLLs.
Did you build for a 64-bit platform in Visual Studio?
A Visual C++ application which is build for a 32-bit environment won't work directly in a 64 bit environment. And although applications will work using the WOW64 compatibility layer, DLLs must be 64-bit if they are to be loaded by a 64-bit operating system.
Since that is indeed the case here, you need to build your project for a 64-bit platform (Visual Studio 2005 and later have a 64-bit compiler).
See the link http://msdn.microsoft.com/en-us/library/ms185328.aspx for more details.
Here is my problem:
I have developed an application which can be run on various platforms, including Windows and Unix. This app runs well on pure Win32 box (WinXP) or a pure Win64 (Win2K3 x64 edition) and other unix platforms.
It only fails when running on a 64 bit Win2K3 in 32 bit mode. This app invokes a third party dll at the runtime. And the third party dlls are not formally installed, but just copied to a location in the same env. I'm also sure I'm having the right version of these 3rd party dlls (I mean 32 bit version for 32 bit mode). Even I manually set the "path" in this testing box, it still doesn't work. The app is compiled and built in 32 bit mode in this Win2K3 box.
I run dependency walker and see the same error. Cannot find that 3rd party dll.
Can anyone shed some lights on this? How do I make that 3rd party dll path visible to my app or the system?
I would suggest you to do the following:
ensure that you are using 32-bit
version of the problematic DLL with 32-bit app
use filemon to see what paths your
application tries while loading that
DLL
check whether it works if you place
that DLL into one of those paths
use dependency walker with that DLL
itself - it might have its own unresolved
dependencies
WOW64 redirects all calls by 32 bit applications to the System32 folder to the SysWOW64 folder. Is the third party DLL in the system32 folder? Because the system32 folder, contrary to what you'd expect, contains ONLY 64bit DLLs on Windows x64.