I have created a small WIN32 Console Application in Visual C++ in Windows 7.
When I try to run this application on Windows Xp it gives me an error saying
This application has failed to start
because MSVCR100D.dll was not found.
Re-installing the application may fix
this problem.
So how do I statically build this application so that it contains MSVCR100D.dll ? or
do I have to copy MSVCR100D.dll form Windows 7 and paste it some where in Windows Xp ?
Thanks.
MSVCR100D.dll isn't a Win7 DLL, it's an MSVC2010 DLL. You can use static linking by changing RuntimeLibrary from MD(d) to MT(d) in the project properties (under C/C++ -> Code Generation).
Related
I have dll project using cpprestsdk in visual studio 2019 (along with console application for testing purposes).
On windows 7 and windows 10 original package works as expected, however I'm having hard time to compile and run on windows XP.
cpprestsdk is included in the project through NuGet, version: cpprestsdk.v141 but, its not visible for the compiler. Line #include <cpprest/http_client.h> throws an error.
Changes i've made:
platform toolset set to Visual Studio 2017 - Windows XP (v141_xp)
preprocessor definitions updated to include CPPREST_TARGET_XP
statically included cpprest141_2_10.dll
statically linked cpprest141_2_10.lib
console application setting ConformanceMode set to false
Now the app is compiling, but it's not working properly on windows 10 (crashes on sending request). and it's not starting on windows XP (dll entry point not found)
Any1 have any idea what's going on?
#edit:
after adding to program folder missing dlls:
api-ms-win-core-crt-l1-1-0.dll
api-ms-win-core-crt-l2-1-0.dll
httpapi.dll
it came to ntdll.dll
Entry Point Not Found error screenshot
The procedure entry point WinSqmAddToStreamEx could not be located in the dynamic link library ntdll.dll
all you need to do is downgrade your Visual studio to 2013 and donwload the version of cpprest SDK like 2.9.1 which support the VS 2013 (msvc 120) as well, hope it helps
I have not enough knowledge on how to fix this. What I do know is:
Build a Executable in Visual Studio 2010 on Windows 8.1 (hence the 1-2-0.dll)
Running the executable, crashes on Windows Vista with the message: "This application could not be started, because of the api-ms-win-core-libraryloader-l1-2-0.dll"
Under vista you would have the libraryloader 1-1-0 if not mistaken?
this library is linked from mscorlib.dll somehow? But not referencing this dll would not build the project.
Maybe someone could direct me in correct way? Or better have a solution for this?
Is there a way to tell VS to not use this latest dll version?
I am certain I did not reference this specific DLL.
I got the same problem, in my case I was providing the d3d9.dll and d3d11.dll, that I copied from windows 8.1 windows instalation directory and ofc. I cant use those!
And then all Computers like Vista, Windows 7 and even Windows 8 had that Error:
"This application could not be started, because of the api-ms-win-core-libraryloader-l1-2-0.dll"
Because this file:
api-ms-win-core-libraryloader-l1-2-0.dll belongs to Windows 8.1
Solution?
In my instaler, Installshield, I removed the d3d9.dll and d3d11.dll, so my aplication will use the ones already in OS.
The problem was not in the "EXE" produced by Visual Studio, but in DLL dependecies that I was providing.
this problem occurred due to Compatibility with older operating systems.
this link may help you
http://msdn.microsoft.com/en-us/library/hh802935(v=vs.85).aspx
I have Win7 64 bit machine and installed Qt library for VS2008 on the machine.
After creating blank Qt application, I get an error "cannot open input file odbc32.lib" when compiling the app in VS 2008. I believe that's a wrong message in several aspects. My machine is 64 bit and surely does not have the library. And why it requires that library for blank app. Is there any way to remove it from linker options? Can anybody give a clue how I can resolve this problem?
Resolved the problem by including Windows SDK library directory (e.g., C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\x64) and its executable directory in VS 2008. And I was wrong. odbc32.ib is still a 64-bit library
I have a developed a C++ application using 32 bit and it create a executable file. This project has uses some external library like window socket 32bit, Qt GUI and boost library. The dll is located at same directory with the executable.
I wonder how can i run this application on window 7.
MY window 7 version is Home Premium 64 bit. Therefore, i cannot install the XP mode from Virtual PC but some one them reported that using Sun virtual box is functional.
I have try to troubleshoot the executable file using program compatibility but the problem doesn't solve.
Any program that can check external dependencies and identified the issues of running my program on window 7 ?
Please help.
Thanks.
64 bit editions of windows can run 32 bit applications fine. You just need to install the 32 bit versions of the needed libraries and it will work.
I have installation solution that have installer project (not web installer but simple installer) that installs NT services, web service and web sites with help of additional two projects of dlls with my own code that performs my installation step. In user actions of installer project I call installer function of one of those projects, and this project calls to installer of second project: installer -> MiddleCaller -> InstallationCore.
All this developing on Windows 7 and work fine when I compile all in 32 bit.
The project must run on Windows 2008. Because of some reasons all must be in x64 bit.
For this purpose, in MiddleCaller and InstallationCore I click right button of mouse on project -> build -> targer x64. For to move installer project to 64 bit in properties of installer (when project is active) I check: Target platform: x64.
When I run installation on x86 I get error:
The installation package is not supported by this processor type"
And this is good, because now I know that my installation compiled in 64 bit, but when I run this on windows 2008 I get:
Error 1001. Exception occured while initializing the instance:
System.BadImageFormatException: could not load file or Assembly
'MiddleCaller, v...' or one of its dependencies. An attempt was
made to load a program with an incorrect format.
Any one has some idea what I need to do for run fine the installation on x64?
May be I still not moved the installer project to x64 bit, if yes, where I do this?
Thank you for ahead.
Found a quick tip on Microsoft's website that could be useful on troubleshooting setup and deployment projects:
64-bit managed custom actions throw a System.BadImageFormatException exception
If you add a 64-bit managed custom action to a Setup project, the Visual Studio build process embeds a 32-bit version of InstallUtilLib.dll into the MSI as InstallUtil. In turn, the 32-bit .NET Framework is loaded to run the 64-bit managed custom action and causes a BadImageFormatException exception.
For the workaround, replace the 32-bit InstallUtilLib.dll with the 64-bit version.
Open the resulting .msi in Orca from the Windows Installer SDK.
Select the Binary table.
Double click the cell [Binary Data] for the record InstallUtil.
Make sure "Read binary from filename" is selected and click the Browse button.
Browse to %WINDIR%\Microsoft.NET\Framework64\v2.0.50727.
Note
The Framework64 directory is only installed on 64-bit platforms and corresponds to the 64-bit processor type.
Select InstallUtilLib.dll.
Click the Open button.
Click the OK button.
There are some unclear things in this scenario. I understand that you are having difficulty running a 32-bit installer that calls on 64-bit assemblies. If this is correct, then what you are doing is not allowed. You cannot have 32-bit and 64-bit assemblies in the same process - that is illegal. If the 64-bit assemblies are being referenced by the installer directly, then the installer must also be 64-bit.
As clarification: I believe a 32-bit installer can install a 64-bit application, but it may only do so by copying the 64-bit files and not by actually making calls into the 64-bit files. The only way this is supported is if the 64-bit files are loaded into a different process and you use IPC to call into them, but even this is likely to be a bad solution.
In your case, I would encourage you to convert your installer into a 64-bit installer.
So, eventually, I compiled MiddleCaller and InstallationCore in AnyCpu mode, when all dll and executables that I need to install were compiled in x64 bit. All this I compiled on Windows 2008 x64 bit with x64 bit outer dependencies (like Oracle client).