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.
Related
I am a self taught software engineer. I am building a desktop application that needs to work on 64 bit windows 7 system.
I am planning to integrate a third party library called FCL C++. In FCL's official documentation page it is stated that it can be built from source on unix or win32 systems.
My question is, if I build a win32 dll of FCl in Windows, would I be able to use it in my win64 application? If not then is there any other ways to go about this?
I am currently developing the software in windows 10, using CMAKE and Qt. Would developing in Linux would be better in this case?
Win32 is a legacy name of the the API set and platform. It applies to both 32 bit and 64 bit Windows. When you build the DLL, you can choose the output to be a it for 32-bit or 64-bit binary in Visual Studio.
While a 64-bit Windows OS can run a 32-bit program (EXE), a 64-bit process EXE can't load a 32-bit DLL. Just build a Win32 DLL for either 32-bit or 64-bit depending on what type of EXE you are building for.
If you are unsure, just build everything (DLL, LIB, EXE) for 32-bit since that runs everywhere.
After porting some of my programs from VS2015 to VS2017 in noticed that the binaries no longer run on Windows 7 or Windows XP - even though they have been compiled with v141_xp toolset. The program fails to start with missing DLL api-ms-win-core-rtlsupport-l1-2-0.dll (note the 2).
I'm well aware that those api-ms-win-* DLL's belong to the UCRT and that, starting with VS2015, I have to redistribute the UCRT DLL's from the Windows 10 SDK (to be found at Redist\ucrt\DLLs in the Windows 10 SDK directory), along with my application - just redistributing the vcruntime140.dll and msvcp140.dll is not sufficient. But there is only api-ms-win-core-rtlsupport-l1-1-0.dll in my Windows SDK directory, but not api-ms-win-core-rtlsupport-l1-2-0.dll. I just downloaded and re-installed the latest Windows SDK (10.0.15063), just to be sure. Still the DLL in question is absent!
I also tried installing the VS2017 Redistributable package on the Windows 7 (or XP) machine via VC_redist.x86.exe - latest version downloaded from Visual Studio web-site (14.11.25325). Obviously that copies the api-ms-win-* DLL's into the "System32" directory. But, again, only api-ms-win-core-rtlsupport-l1-1-0.dll, but not api-ms-win-core-rtlsupport-l1-2-0.dll. App still won't start.
[EDIT]
This of course only applies if I link against the DLL runtime (/MD). If I link against the "static" runtime (/MT) I get a binary that has no DLL dependencies on UCRT and runs fine on Windows 7 and XP.
[EDIT #2]
Please refer to my other post (including EDIT) for the resolution of the mess:
https://stackoverflow.com/a/45773325/1766377
Okay, this is quite interesting: Just now my VS2017 found a new update. Apparently that updated my VS2017 from v15.2 to v15.3.1. The runtime libraries were updated as well, it seems!
There are now two directories, VC\Redist\MSVC\14.11.25325 and VC\Redist\MSVC\14.11.25415, inside my VS2017 install directory. The vcruntime140.dll exists in both directories. But the newer version (25415, right) has quite different dependencies, compared to the older one (25325, left):
Only the "new" version has dependencies that are missing on Windows 7. So, I should be fine going with the "old" version. But it means I'm locked to the "old" version. Is this normal / intended ???
(BTW: Both DLL versions from VS2017 v15.3.1 are newer than the one I originally took from v15.2)
[EDIT]
So, it was just brought to my attention that there is a subtle difference between the VC\Redist\MSVC\14.11.25325 and VC\Redist\MSVC\14.11.25415 directories: The 25415 directory has all DLL files inside another sub-folder called onecore, the other one doesn't. Apparently, this means that the "newer" DLL versions (the one with onecore sub-folder) are not supposed to be redistributed with normal Desktop applications; they are strictly for the "OneCore" Mobile/IoT platform.
Conclusion:
M$ did a great job to design the Redist directory structure as confusing as possible. Putting the version numbers of the "normal" and the "onecore" redistributables on the same level of the directory hierarchy (rather than having separate onecore and desktop directories on that level) indicates that those directories represent different versions of the same thing - which isn't the case at all :-/
Do *not* redistribute any */onecore/* DLL's with normal Desktop applications!
In the property pages for the project, try changing the Windows SDK version from 10.0.15063.0 to 10.0.10240.0. I think that will fix it, provided that the older SDK is installed on your build machine. Something else to try is to change the platform toolset to v140_xp. VS 2017 then builds with the VS 2015 tool chain, provided that VS 2015 is installed.
My personal preference is to avoid any 'DLL hell' by linking with the static runtime, although this won't work if an exe and a dll need to share a heap and incurs some space penalty if you are building several binaries (I just have two).
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.
I've a dll which I've built in Windows7 (64bit OS) in 'Win32' platform. Unfortunately, when I import this dll in C# code, I encounter:
"
an attempt was made to load a program with an incorrect format
HRESULT: 0x8007000B
" is observed
When I used DependencyWalker for this DLL, it shows IESHIMS.dll and MSVCR110.dll dependency which could not be found.
From where these dlls come from and why my created dll has dependency over these two?
Pl help how can I getg over this?
Note: I've used x86 platform in my C# code.
IEShims.dll is available on Windows Vista or Windows 7 to handle protected-mode Internet Explorer 9 or newer. Further explanation here.
You should be able to obtain a copy from another Windows 7 machine with Internet Explorer 9 or newer. As a quick fix, get the Windows 7 version from http://www.dll-files.com/dllindex/dll-files.shtml?ieshims
You probably don't have the C++ runtime installed. Download it and install it. You have to play with the versions of runtime a bit. There are quite a few versions available. This will take care of your MSVCR110.dll issue. I am not sure why the dll show dependency for an IE dll though.
Make sure you chose x86 for the target architecture in the properties of your C# project.
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.