just created and compiled a simple "Hello world" in C in Visual Studio 2013 for testing purpose as some service I wrote didn't work on a Windows XP machine (yes I know it's ultra old, never mind).
So I thought I'd test with "hello world". I know that I need to select a Windows XP compatible environment in the General Settings of the Visual Studio project, done that. Tried MT and MD, so static or dynamic. Both gives me the same result: Nothing. Just a blank command line. I don't get it.
Any ideas what might be missing? I'm afraid I don't have full access on the XP system, just a command line shell, that's it. But I guess that wouldn't make a real difference.
I tried other command line tools which tend to work just fine, just my own compiled ones do nothing. Source code, just so noone asks ;-)
#include <stdio.h>
#include <Windows.h>
int main(int argc, char *argv[])
{
printf("Hello World\n");
return 0;
}
Hm...aaaannoying:-)
The platform toolset should be set to XP in your project.
The VC++ 2013 runtime should be present on the test machine.
Build in release mode. Else you will have to copy the VC++ debug dlls to your applications bin folder while deploying on to the test machine
Set the _win32_winnt preprocessor to XP i.e. #define _WIN32_WINNT 0x0501
Ok, funny, as Ganesh R. rightly pointed out: It does not work with Visual Studio 2013 anymore.
So I switched to Mingw and,...perfect!
Related
When I compile a simple program:
#include <iostream>
using namespace std;
void main() {
cout << "Hello world!";
}
And tun the compiled .exe on another system without visual studio installed I receive the following error:
The Code execution cannot proceed because VCRUNTIME140.dll was not found. Reinstalling the program may fix the problem.
When I compile with cl.exe I receive no errors,
does anyone know a workaround to this without installing VCRUNTIME140.dll on the systems. (I've tested on multiple windows systems including a windows virtual machine)
I've encountered this problem before and there's a simple solution to it,
The missing .dll are a issue of static linking not missing packages (in most cases),
becuase visual studio 2019 comes pre-installed with what you need.
To fix:
go to your project properties (in project tab)
Select C/C++
Change the value of runtime library to "Multi-threaded debug (/MTd)"
This will cause the compiler to embed the runtime into the app.
The executable will be significantly bigger, but it will run without any need of runtime dlls.
Get the "Visual Studio 20xx VC++ Redistributable package" for your version of Visual Studio. Then run on the target machine to install.
Bottom of this page: https://visualstudio.microsoft.com/downloads/
Or bottom of this page for older versions of Visual Studio: https://visualstudio.microsoft.com/vs/older-downloads/
I've had the same problem, mainly because originally when compiling something with C++ and turning it into an exe file, it's still gonna be an exe file that depends on libraries from C++.
But according to asd plourgy, who had a good idea to change the value of the runtime library, I wanted to share with whoever seeks knowledge how I solved it:
Go to your Visual Studio Code and follow these steps:
Click on Project
Properties
Scroll out C/C++
All Options
runtime library
Change value to: "Multithreaded-DLL (/MD)".
And that should do the trick. Afterwards, you have to obviously
save
debug
create new(exe)
open cmd and run the exe to make sure it works.
My System is: Windows 10
Here are a few pictures to make the steps easier, it's in german though:
step1:
step2:
step3:
step4:
step5:
I am using Visual Studio 15 2017 with the v141_xp toolset to compile a Win32 app for Windows XP. The app will run fine on both Windows 10 and XP, but running some Windows API commands like _chdir and _mkdir (or CreateDirectory) don't seem to work right: The directory is not created or, in the case of _chdir the application doesn't change its working directory.
I thought the issue was paths with spaces in the name, but I'm not entirely sure this is the case. I properly use \\ and "\"" in strings where needed, but when manipulating paths like this, it seems to either work in XP, but not 10, or it works in 10, but not XP.
I wish the code to work properly on both. Are there other compatibility issues that I'm missing?
Thanks.
More Info
I am compiling with /MTd 'Mult-threaded Debug' because of portability requirements. It's looking like this may be some issue with CRT being compiled in.
It turns out that the bug was with stat and described here a little more here:
Visual C++ 2015 express: _stat not working on Windows XP
My application was using this existence test for a file or directory, which has been a convenient cross-platform solution for many years:
return (stat(path.c_str(), &st) == 0);
But if you are compiling for Windows XP using a newer toolset, stat is now broken and you have to use the Windows API like:
return (GetFileAttributes(path.c_str()) != INVALID_FILE_ATTRIBUTES);
I have written a portable program in C# with certain dependencies (.NET Framework, Visual C++ redistributable, etc) that will run on Windows XP SP3 and up.
Because of that, the program needs a launcher that will run every time before the actual program does, checking that all the required dependencies are installed. If any of the dependencies are missing, an option to download and install that dependency, will be offered. If there are no missing dependencies, then the actual program is executed.
The launcher itself is relatively simple, consisting of some registry checkup and some WinAPI calls to verify the installed dependencies.
The file structure in the end will look something like this:
C#_compiled_portable_program.exe
C++_compiled_launcher.exe // executes on any system as low as a clean Windows XP SP3 install
The problem is that I have no idea how to compile a C++ code in Visual Studio 2013 that will run with absolute bare minimum dependencies (running on the runtime libraries that come with Windows XP SP3, at least).
Take for instance the absolute simplest C++ code:
#include "stdafx.h"
int _tmain(int argc, _TCHAR* argv[])
{
printf("Hello world!");
return 0;
}
If I compile this with Visual Studio 2013 with the default configurations, it will not execute on a machine that doesn't have VC++ 2013 installed, showing some nasty errors.
I looked around for similar questions and the closest I could find was
Visual Studio 2010 MSVCR dependency removal?, but the answers are either incomplete or outdated.
So, just like an installer, is it possible to compile a C++ project in Visual Studio 2013 that will run pretty much on any system?
This is not perfect, but will do for now.
This is what I did to make a C++ project, compiled in Visual Studio 2013, execute ona system that doesn't have VC++ 2013 installed.
I created a new C++ project in Visual Studio 2013, File>New>Project>Visual C++>Win32 Console Application
Then in Solution Explorer right click the project and select Properties.
Click the Configuration drop down menu and select All Configurations.
In Configuration Properties>General, set Platform Toolset to Visual Studio 2013 - Windows XP (v120_xp).
With Dependency Walker determine what modules are imported by the compiled exe (the release build, not the debug one). The imported modules should be:
c:\windows\system32\KERNEL32.DLL
c:\windows\system32\MSVCR120.DLL
KERNEL32.DLL is a system file so we don't have to worry about that, and MSVCR120.DLL is the Visual C++ 2013 Runtime Library and we need to distribute this file along with the release build. When the executable needs to load a module, it first looks at its current location for that file and then in PATH (System32, etc). If we copy MSVCR120.DLL at same location the release executable is, then the program will run even on systems without VC++ 2013 installed.
Since the project is a 32-bit application, download VC++ 2013 Redistributable x86, install it on a 32-bit version of Windows (I installed it on a fresh Windows XP virtual machine), and copy c:\windows\system32\MSVCR120.DLL.
Update:
Never mind. You don't have to distribute a copy of VC++ Runtime DLL file, you can just configure the project to link statically to the runtime library.
Here is explained how to do it. You'll still have to change the Platform Toolset though, if you plan on executing on Windows XP.
I have recently upgraded from Visual Studio Express 2010 to Visual Studio 2012 Express for Windows Desktop. I'm aware of the previous lack of compatibility targeting Windows XP, but thought this was resolved by Update 1 (which I have installed).
However, I'm still having difficulty targeting Win XP with the C++ applications I have compiled using 2012 Express. I have set the Platform Toolset to "Visual Studio 2012 - Windows XP (v110_xp)" but this makes no difference. When I try to run my compiled application on my Windows XP system (I run Windows XP via VirtualBox), I get an the error that my application "is not a valid Win32 application."
I have also tried setting the CLR Support to "No Common Language Runtime Support" and the Runtime Library to "Multi-threaded (/MT)".
Even with a very basic blank C++ project using the following code, I just can't get it to run on XP:
#define _WIN32_WINNT 0x0501
#define WINVER 0x0501
#define NTDDI_VERSION 0x0501
#include <iostream>
int main()
{
std::cout << "TEST" << std::endl;
std::cout << std::endl << std::endl << "Press ENTER to close this window.";
std::cin.get();
return 0;
}
Can anybody tell me where I'm going wrong with my compiler/project settings?
P.s. I have installed the MS VC++ 2010 and 2012 redistributable packages on my XP virtual machine. Applications that I compiled with Visual Studio Express 2010 work fine on my XP virtual machine.
Check your project's "Configuration Properties -> Linker -> System -> Subsystem" properties.
If blank, fill it with (/SUBSYSTEM:CONSOLE) or (/SUBSYSTEM:WINDOWS).
This works:
Configuration Properties -> Linker -> System -> Subsystem =
/SUBSYSTEM:WINDOWS
Configuration Properties -> General -> Platform Tool Set ->
SubsystemVisual Studio 2012 - Windows XP (v110_xp)
Using Visual Studio 2012 Express Update 3.
Use GNU GCC tool chain, bro, that redistrebuted with mingw. MSVS actualy just minimize dependencies, but some of them still stay in exe. Just compiling in gcc suports full static linking, with small exe size and stable compatibility.
The message is indicating that your build isn't producing a 32 bit application--if it were a version dependent API, for example, you'd see another error indicating that the symbol can't be found. Since you have indicated that you are using the correct target platform in the configuration manager, check your property explorer to make sure you don't have conflicting arguments or defaults. If you see link with the option /MACHINE:X64, then you've found the problem.
If that doesn't work, I suppose you could try running Sysinternals process explorer to see which cl/link are actually being launched with which arguments. Hope that helps.
I'm running Windows 7 and Visual Studio 2008 Pro and trying to get my application to work on Windows XP SP3.
It's a really minimal command line program so should have any ridiculous dependencies:
// XPBuild.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
int _tmain(int argc, _TCHAR* argv[])
{
printf("Hello world");
getchar();
return 0;
}
I read somewhere that defining several constants such as WINVER should allow me to compile for other platforms. I've tried the added the following to my /D compiler options:
;WINVER=0x0501;_WIN32_WINNT 0x0501;NTDDI_VERSION=NTDDI_WINXP
But that made no difference. When I run it on my Windows XP machine (actually running in a virtualbox) I get the following error:
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
So what have I missed? Is there something else required to run MSVC compiled programs or a different compiler option or something else?
What you have missed is most likely that VC++ programs require a runtime to be installed (unless you link statically, which is not the default) - the error message you show is exactly the one you get if they're not in order.
Try installing the Microsoft Visual C++ 2008 SP1 Redistributable Pack on the XP machine - you will most likely see that your program works with no changes whatsoever.
Michael's answer explains why it doesn't work for you, and what you should do about it. With respect to WINVER - they don't change anything about your binary in a sense that it would suddenly start working on XP. What they do is disable function and type declarations in Windows headers files that are not supported on the OS version specified by WINVER. This ensures that you do not accidentally call e.g. some Vista-only function. However, you don't strictly need it - if your code does not rely on any Vista/7-only functionality, you can compile without redefining WINVER, and it'll still work fine on XP.
Just Set the compiler to use static linking in the project settings (Project -> Properties -> Config Properties -> C/C++ -> Code Generation -> Change "Runtime Library" to /MT or /MTd instead of the default /MD or /MDd)