I have been working on a VS 2005 project and have successfully generated an exe file which works fine on my system. However when I tried to run it on some other pc it didnt run. It throws up the error message "the system cannot run the specified program". Can someone tell me how to make my code immune to such message i.e. system independent?
platform used: Windows XP, VS 2005
the extension of all my code files is cpp but I know only c and thats what I wrote inside them.
I have seen before exe created on Windows Sp1 not working on SP2 and problems such as that.
This should help you perhaps.
I've seen this when you run on a different version of Windows that doesn't have some DLL you depend on. The easiest thing to do is statically link the C runtime (that's the usual culprit) and use depends.exe to see if there are any others.
You will almost certainly need to create an installer that installs your executable and any non-OS-included DLL's it relies upon. It is not always possible or desirable to statically link all dependencies. You can in many cases simply copy the DLL's to the same folder as the executable.
By default, even the C/C++ standard library is provided by a DLL. While the MSVCRT.DLL used by VC++ 6 is included with the OS since later editions Win95, the MSVCRT required by VS2005 is not included with XP installations (other versions I do not know). The run-time support is included VC redistributes package. You may need to arrange for your installer to include that installation, or you could be more selective is you know your dependencies.
Some Win32 API calls if you are using them are dependent on the OS version (check the documentation), but if you built and rin it on XP, it should normally work of any subsequent version of Windows. You need to define various API version macros if you want to extend support to earlier versions of Windows (which seems unlikley).
You might need to install the VS 2005 redistributables on the other machines, depending on how you have compiled your program.
Related
When I compile C++ code that uses openmp libs with visual studio, the program is very portable - because it runs in other machines with Windows without problems.
When I compile the C++ code with Eclipse CDT (oxygen and g++ cygwin) for Windows, in general, I need to install the correct runtime libs in the other machines to be able to run the program. I don't find it practical.
Based on this:
1) What is the right way to compile the code including all libs (g++ and openmp) to run in another Windows system?
2) How can do this in Eclipse CDT for Windows?
The problem is not in compiling, but in distributing. Windows and windows toolchains intend to use dynamic linking. Now, if created software are dependent on particular version of runtime, which includes side-by-side build, they can be run only if exactly that build is installed. Several builds of same library version may exist, they are fetched using side-by-side (SxS) mechanics.
On Linux platform this problem is solved through package manager and dependencies. On Windows you have to create an installer, which would contain or have ability to download proper version of libraries. Also installer may do proper changes to OS settings, and register them , for future rollback.
Note, that runtime libraries have debug variants which cannot be distributed and debug build of software must be run on developer system only.
"Portable" apps that appear here and there and can be run without installation, have special status not to be dependant on SxS run-time library. To my knowledge cygwin and mingw32 allowed to create such, the 64bit project of mingw had problems with that. But they are still dependant on particular versions of system .dll and may break or malfunction in case of mismatch.
Even in that case you still need some .dll, from mingw, cygwin, Qt, whatever you use and what is not a part of OS, to place them where program can reach them. Which can be folder comtaining the executable. Static linking became a gimmick of past for desktops, because of code bloat - dynamic library size easily can be dozens of megabytes.
And last: you don't compile anything with Visual Studio or with Eclipse CDT. Both designed to use various compilers, it's juse environments. You have to specify normal;y, what compiler your IDE uses, not what IDE you use to run ot.
I’m developing some Windows software that's sometimes used in embedded-like scenarios. That’s not uncommon for my users to have a dedicated Win7 or Win8 PC they never update, not even connect to the Internet. Users plug those PC to a specific industrial hardware, and use that system for one job only.
My software includes components I've written in Visual C++. I include CRT in my MSI packages using appropriate installer merge modules.
Unfortunately, for a PC that never updated, that doesn’t work: today I got a bug report, the app crashes on startup saying “can’t start because api-ms-win-crt-stdio-l1-1-0.dll is missing from your computer”
This answer suggests static link to CRT.
Did that. But some parts of my C++ code rely on OpenMP for parallelism.
Dependency walker shows me the DLL I’m building depends on vcomp140.dll even when compiled with Multi-threaded (/MT) runtime library settings.
Also it shows vcomp140.dll only depends on kernel32.dll and user32.dll.
Can I just place that single DLL, vcomp140.dll, in the installation folder? Will it work on offline Windows 7 PC?
Based on the VS2015 Redistribution List I would say that copying that file would be indeed what you need to do and would work fine (if you used VS2015 to build your app). Take care to copy the proper dll based on arm/x86/x64.
Just to make it clear, it is not possible to statically link openmp with Visual Studio. Only two things you can do:
Remove openmp (and compile with /MT /MTd)
deploy vcomp140.dll (or VC redistributable) with your application
Are the dynamic runtime libraries for Visual C++ (more specifically 2008) part of the Windows OS nowadays? I noticed that at least on Windows 8 you no longer need to ship these with your application or have the user install the redistributable package from Microsoft.
Is this true? If so, for what Windows versions and for what versions of Visual C++ does this apply to?
No, they've never been part of the Windows distribution. Deploying them yourself is a hard requirement.
It certainly may seem that they are. Starting with msvcrt.dll in the system32 directory, it has the same name as the C++ runtime dll in Visual Studio versions prior to VS2002 (VS6 and earlier). It is however a private copy of the CRT that is used by Windows executables. And protected by the File System Protection feature in Windows, preventing old installers from destroying the operating system.
It certainly often works by accident. There are many programs that need the Microsoft CRT so it isn't unlikely that the user has run an installer before that got the DLLs installed. Clearly you cannot depend on that common accident.
Similarly for Windows 8, the pre-installed Microsoft.VCLibs.110 package matches the package you need for a Store app written in C++. But that's for the same reason as above, Microsoft Store programs were also built with VS2012, just like yours. What's going to happen in the upcoming VS2013 is a bit muddy right now, we'll know soon.
In my opinion, the answer would be both: Yes and No.
Yes: More recent Windows OS are generally shipped with VC runtimes pre-installed (along with more recent versions of the .NET framework). It is because Microsoft uses the latest/newer Visual Studio before they release VS to the public (or even to MSDN subscribers). If not this way, whenever you install some application (legacy application or some downloaded application), the setup would anyway install the required VC++ runtime. Another way is through automatic updates.
No: In case where none of the above mentioned rules applies. Or, when the VC runtime shipped with a new service pack or a patch. You might have developed your application with newer patch/SP, and that must be installed (as Side-by-Side, of course).
I have a Win32 app developed in C++ Builder XE, which has worked great in the WinPE 2.x/3.0 environments for the past couple of years. I have made some significant changes over the past couple of months, but now that it's complete and I try to run it under WinPE I get the error message: The program can't start because SHFOLDER.DLL is missing from your computer.
Since I can't control the WinPE environment, and this dll isn't included in WinPE, my first thought is to try and statically link the necessary components. However, it appears the functionality offered by this dll is only available from the dll.
I haven't been able to find any useful information on this DLL, and unfortunately I don't know which functionality I added that now requires this DLL. I am hoping that someone has experience with this, and can help guide me toward statically linking the required components, or finding a workaround so that this app no longer requires the dll. Thanks!
shfolder.dll is used to get shell folder paths like the Desktop, My Documents, Windows directory, etc. It implements SHGetFolderPath() consistently along all versions of Windows due to differences of implementation between SHGetSpecialFolderPath(), SHGetFolderLocation(), SHGetKnownFolderPath(), etc.
MSDN explains it better:
This function is a superset of SHGetSpecialFolderPath, included with
earlier versions of the Shell. On systems that preceded those that
include Shell32.dll version 5.0 (Windows Millennium Edition (Windows
Me) and Windows 2000), SHGetFolderPath was obtained through
SHFolder.dll, distributed with Microsoft Internet Explorer 4.0 and
later versions. SHFolder.dll always calls the current platform's
version of this function. If that fails, it tries to simulate the
appropriate behavior. SHFolder.dll continues to be included for
backward compatibility, but the function is now implemented in
Shell32.dll.
The DLL itself is redistributable so you can include it for WinPE. You can also just use any one of the other functions, if they work for you and you don't need any of the special cases.
What's in MS Visual C++ runtime library? I mean, I googled it, and I always found things like help, app xxxx gives me MS Visual C++ runtime library error, with no explanation.
I thought that Windows C runtime libraries come with Windows? Not with VC++? Thanks.
EDIT:
First, thanks for answers. I thing now I have bad idea of runtime libraries in windows. I mean, the first part, that Windows internally has its win32 API and so, that's OK, I knew it. Also, that Win32API are from kernel and user parts.
But I always thought that functions like GDI are accessed as DLL (which I still believe they are). But I thought even functions like printf and so are in some windows file.
So, am I right, when I know get it that "simple" functions like printf need to be linked directly and than use only Kernel part of OS directly, and more sophisticated Windows API functions are linked as dlls, therefore ARE NOT distributed with compiler but with OS? And they subsequently access Kernel?
I mean, lets say GDI, I tell it to draw picture, it makes all the hard work in user mode and than call kernel function which puts it all in framebuffer?
And last thought, why is this even solved this way? I mean, if VC++ runtime is just layer between C and WinAPI, why cant VC++ call directly WinAPI?
This is an oversimplification, but it will give you the gist. The MSVCRT is a set of DLLs that implements parts of the C++ language. Functions like printf, memcpy and the like are implemented in these DLLs.
Every program that is compiled with a particular compiler and dynamically linked to the C++ runtimes must somehow have the correct version of the CRT binaries on the target machine. As a result, applications that ship to end users are often (usually?) also shipped with a package of these DLLs. This package is called a "redistributable" (or "redist"), and there is a different one for every combination of exact compiler version and target platform. For example, there are seperate and distinct redists for each of the following:
MSVC 10, 64-bit windows
MSVC 10, 32-bit windows
MSVC9, 64-bit windows
MSVC9 SP1, 64-bit windows
et cetera.
Yes, Windows usually "comes with" some version of the CRT. However, it comes with the version(s) that it needs in order to run the apps that shipped with Windows. If Windows and all it's apps were compiled in MSVC8 SP2 and your app is compiled in MSVC10, the CRT you require won't be present on the box simply because it's running Windows.
This is why its common practice to ship apps along with redists.
EDIT:
By way of Houdini like magic, I predict your next question will be "where do I get the redists?"
The answer is, from MicroSoft. Try a google search for "msvc 9 x64 redist" and you will find:
http://www.microsoft.com/downloads/en/details.aspx?familyid=bd2a6171-e2d6-4230-b809-9a8d7548c1b6&displaylang=en
A brief answer would be that the MSVS C/C++ runtime implements functions like malloc/free, stdio, iostream and some c++-stuff like dynamic_cast and exception handling. These differs between versions of visual studio, so there are different runtimes for different versions.
Windows ship mostly with a C API (the Win32 API) which rather different from the C/C++ standard library. The MSVS C/C++ runtime calls into this API to allocate memory, etc etc.
(I suppose some of the applications included with Windows are written with MSVS and in C++, so they do include the MSVS runtime for that version.)
Also, the runtime changes as new Visual Studio versions are released. A Windows release lasts much longer than that.
They are the libraries that implement the C and C++ standard library functions. Standard functions such as printf are implemented in these libraries.
The core Windows libraries only provide interfaces to system calls, i.e. the Win32 API, since that is all you need to build a full-featured Windows application. The VC++ libraries are mostly wrappers around this API, and are analogous to the glibc library on Linux.
As an example, malloc from the C library might in turn use the VirtualAlloc API to allocate memory.
Programs compiled with Visual C++ require a "runtime" - this is a bit of code that handles application startup/shutdown, memory allocation/deallocation, support for reading and writing files, etc.
This is not part of the operating system, and not part of the final application - Because all C++ applications can share it, by default the runtime is a separate installation.
In addition, each version of Visual C++ has its own runtime installer, because with each version there are slight differences and improvements in the way all this works. There are also different verisons of the runtime for different platforms (e.g. x86 and x64)
Hence, there are a number of "Visual Studio XXXX runtime installer (YYY)" downloads available from Microsoft, where the XXXX is the visual studio version (2005, 2008, 2010, etc), and YYY is usually "x86" or "x64".
Most applications that need the runtime will automatically install it if needed, so generally end-users are not very aware of these redistributables.