I'm using Visual Studio 2019 and trying to compile a program that was compatible with Windows XP 32-bit.
When I first ran my .exe on my VM it said that it wasn't compatible with Win32.
I've then changed the Platform Toolset to Visual Studio 2017 - Windows XP (v141_xp).
Now it says I'm missing a VCRUNTIME140d.dll, and following instructions that said to change my Runtime Library to /MT I get the error stated in the title.
Any suggestions would be very much appreciated.
VCRUNTIME140d.dll is Visual C++ Redistributable for Visual Studio 2015.You need to download and install. And this is Debug versions of DLL. You must compile in Release mode.
Related
I am trying to do simulation using Delmia. This requires a functioning C compiler. When i test my C compiler in Delmia, which tries to compile a very simple source file that includes stdio.h, I get the error "Cannot open include file: 'stdio.h': No such file or directory":
Compiling and linking the model (Visual C++).
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.6.2
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x86'
Guessed compiler version: 1913
"Testing 32-bit compilation"
dsmodel.c
dsmodel.c(1): fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory
Error generating Dymosim.
It seems to be entirely the same issue as:
Visual Studio 2017 for Dymola cannot open stdio.h
His solution is not descriptive enough for me to solve my issue, as his "IT dept" apparently solved it for him, but he mentions allowing access to regedit which I do not understand the reason for in this context.
I have tried to recreate the error that Delmia generates by compiling dsmodel.c with VS2017 Developer Command Promt. If I run the command prompt in Administrator it compiles fine, if I do not, I get the samme error as Delmia outputs. Why is this?
If I find a solution such that I can compile it with command prompt without being in Administrator mode, then should Delmia not also be able to? How can i achieve this?
Some additional information: I have installed Visual Studio not on my main drive, and the Windows SDK is in program files on my main drive. Does this have any relevance?
Edit: For anyone else with this issue in Delmia, I would suggest simply installing another compatible compiler as a work-around. I installed MinGW which works well, even though this additional compiler takes up 500 MB. Remember that it has to be 64-bit. I used the "MingW-W64-builds" from http://mingw-w64.org/doku.php/download
I have a c++ application built in Visual studio 2015, It seems c++ apps have need visual c++ 2015 (In my case) to be installed (on targeted windows version). Then i decided to convert my c++ source to c and use CLion 2018 for build this project. It has no error but the output executable has visual c++ 2015 (It says: vcruntime140.dll is missing) dependency again. Here is my questions:
Does C written executable's have any external dependencies ? What are those dependencies ?
Im new to CLion2018, How to build c projects to work without dependency on all windows versions and architectures ?
Is still any way to use VS2015 to create and build c projects ? (Already tried changing compile as: option to /TC and changing extensions to .c. Build was successful but Output has VCRUNTIME140.dll error).
Note1: Both output files (In CLion and VS) are working on windows 7,8.1,10 with visual c++ 2015 installed. And both have "VCRUNTIME140.dll is missing" error on raw windows 7,8.1,10 without visual c++ 2015 installed.
Note2: Don't want to pack those dll's with my file, Or installing vc++ 2015.
I have a custom dll written for MATLAB and it works fine on our development machines. However, when I try it on a clean machine with no development tools, I get the message:
>> loadlibrary CMatLab CMatLab.h
??? Error using ==> loadlibrary at 279
Microsoft Visual C++ 2005 or 2008 is required to use this feature.
After some research it seemed clear that a compiler was required to parse the header file at runtime, so I installed the standard Windows SDK, ran mex -setup to select the compiler but I still get the same error message. This is what I did for select the compiler.
>> mex -setup
Please choose your compiler for building external interface (MEX) files:
Would you like mex to locate installed compilers [y]/n? mex -setup
Select a compiler:
[1] Microsoft Visual C++ 2008 SP1 in C:\Program Files (x86)\Microsoft Visual Studio 9.0
[0] None
Compiler: 1
Please verify your choices:
Compiler: Microsoft Visual C++ 2008 SP1
Location: C:\Program Files (x86)\Microsoft Visual Studio 9.0
Are these correct [y]/n? y
***************************************************************************
Warning: MEX-files generated using Microsoft Visual C++ 2008 require
that Microsoft Visual Studio 2008 run-time libraries be
available on the computer they are run on.
If you plan to redistribute your MEX-files to other MATLAB
users, be sure that they have the run-time libraries.
***************************************************************************
Trying to update options file: C:\Users\adriane\AppData\Roaming\MathWorks\MATLAB\R2010b\mexopts.bat
From template: D:\Matlab\bin\win64\mexopts\msvc90opts.bat
Done . . .
I really do not want to install Visual Studio on this machine as it reduces it's utility as a testbed for release builds of our other tools and software. Any ideas anyone? I see that others have the same problem but I did not see a clear solution. The OS is Windows 7 pro 64 bit. The dll was built with VS2008.
Try using the 'MFILENAME' option to loadlibrary to produce a "protofile", which can be used in the future to load the DLL via the #PROTOFILE syntax. Generate the file on your development machine, and bring it along to the test machine.
So, on the dev machine:
loadlibrary('CMatLab', 'CMatLab.h', 'mfilename', 'cmatlab_proto');
Bring along to the test machine the DLL, the file labelled 'thunk', and cmatlab_proto.m. On the test machine, run:
loadlibrary('CMatLab', #cmatlab_proto)
Executable generated by vc8 C project (in windows 7) is running in all windows machine (both win xp and 7) in which vc8 is installed. But its not running in one win xp machine where vc8 is not installed, but vc6 is installed. Error message is System cannot run the executabe.
Is it happening because my vc8 project is not generating vc6 compatible exe ? Please some one help is there any way to solve this problem.
Note : Creating vc6 project and adding all c files is a complex task, which will take so much time for me.
You don't need to have visual studio installed to run an application on another machine. Compile in release mode and install the redistributable package on the target machine.
For VC8 (2005):
VS 2005 x86
VS 2005 x64
for other versions just search for c++ redistributable package
EDIT:
If you compile in debug mode you need the debug versions of the runtime library etc. However these are not redistributable. For a workaround (for use on testing machines, not for clients) see here for more details.
I was working with visual studio 2012 beta and my desktop (win32) program compiled fine in ARM architecture.
After upgrading to visual studio 2012 RC, the compiler would not work and spews out the following error:
"Compiling Desktop applications for the ARM platform is not supported"
I found a forum post on this
http://connect.microsoft.com/VisualStudio/feedback/details/745580/arm-configuration-doesnt-work
Is it correct that Microsoft is really cutting off win32 development on ARM?
And that compiling in VS2012 beta was just a fluke?
You can edit the file:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Platforms\ARM\Microsoft.Cpp.ARM.Common.props
In the <PropertyGroup> section add the line:
<WindowsSDKDesktopARMSupport>true</WindowsSDKDesktopARMSupport>
before </PropertyGroup>
And that's all, you can build ARM desktop apps with VS2012.
I was able to get around that error and compile a little "hello world" cpp file for ARM by adding the "/D _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE" command-line argument to the ARM version of cl at C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_arm. I found that #define from sn0w's answer on this question in the crtdefs.h file, without having to modify that file. Now, I can't guarantee that anything more complex will actually work, or that Microsoft hasn't instituted some sort of whitelisting or digital signature verification for Windows RT desktop apps, so even though it may compile, it may not be allowed to run when Windows RT is finally available.
Note that before you can run the ARM version of cl.exe from the command line, you must set the environment variables using this batch file: "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_arm\vcvarsx86_arm.bat"
Even if you compile the app, you won't be able to run it on Windows 8 RT as unsigned apps will not start.
I just tested this, and unfortunately it is the case.
You receive the following message:
Windows cannot verify the digital signature of this file
I imagine there is probably a work around for this, but it will never be officially supported.
yes of course. i practised with VS2012 RC.
now i'll explain how to avoid "Compiling Desktop applications for the ARM platform is not supported" and build win32 application.
1st way: fix build tools - the goal is to patch (or try to substitute it with beta's one) MSBuild's lib: Microsoft.Build.CPPTasks.Common.v110.dll
2nd way: run the "VS2012 ARM Cross Tools Command Prompt" from Visual Studio Tools start menu, then execute cl [cl params] myfile1.cpp myfile2.cpp myres.res ... /link [linkparams]
for both this cases you also need to commentout an #error directive in crtdefs.h on line 332. (Microsoft Visual Studio 11.0\VC\include)