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.
Related
I recently read that C/C++ runtime in windows has 2 parts. First is VC Runtime and other is Universal C Runtime.
As per my reading , Universal C runtime is part of the OS.
Question 1 : So does it comes with OS installation by default? Or has the Universal C Runtime to do something with Windows SDK i.e Windows SDK install provides UCRT?
Question 2 : If the UCRT is part of OS, then what supplies the VC Runtime?
Also, I read that platform toolset provides compiler, linker and standard libraries.
Question 3 : So platform toolset has nothing to do with C/C++ runtime (which is split in 2 parts)? Can we say that platform toolset and C/C++ runtime don't come as single unit on windows OS?
Please clarify.
Universal C runtime comes with the OS on Windows 10 (it's installed when you install the OS). On older Windows versions (Vista through 8.1), it is distributed through Windows Update. It can also be locally deployed with your app.
If your app supports an OS older than Windows 10, you need to think how you're going to distribute it. You can either include a copy of it with your app (this is the most common solution) or you can require the Windows Update for it to be installed.
You can read more about it here: https://learn.microsoft.com/en-us/cpp/windows/universal-crt-deployment?view=vs-2019
VC Runtime can be supplied in two ways: through Visual C++ redistributable packages installer, or deployed locally with your app. If you ship an installer with your app, you can have your installer also install VC Runtime packages. If you ship software that doesn't get installed, you will have to drop VC Runtime DLLs next to your application executable. You can read more about deploying with VC Runtime here: https://learn.microsoft.com/en-us/cpp/windows/redistributing-visual-cpp-files?view=vs-2019
Also, I read that platform toolset provides compiler, linker and standard libraries.
This is not entirely correct. It provides standard C++ libraries and runtime (also known as VC Runtime). Standard C libraries and runtime come from Universal C Runtime.
"Universal C Runtime" is, at best, peculiar terminology.
The C compiler comes with a standard library that you link into your code. The standard library provides all of the functions required by the C standard. It's up to the library implementor to figure out how to implement them.
The operating system provides services that are useful to programs: memory management, file system, display screen, keyboard input, mouse, whatever. It has its own interface, and code in the standard library uses it as appropriate.
Different operating systems have different ways of providing these services, so the standard library has to be written differently for different operating systems. But calls to the operating system are not necessarily written in C, which is why "Universal C Runtime" isn't really appropriate. For example, back in the olden days of MSDOS, calling the operating system meant setting some values in processor registers and then generating a software interrupt. That's generally not C code, although some runtime libraries provided a code layer so that you could do that without having to write your own assembly code.
I want to learn C++ and I want to know if using Microsoft VC++ will tie me to Windows. I specially need my project to also run on Mac. My projects are all Class libraries and have no dependency to UI. They are just calculations or file/network IO.
I really like working in Visual Studio and Microsoft way overall. So my priority is to go VC++ unless it makes painful to build cross platform apps for Windows and Mac. I mean at the compiler, libraries and language level. I don't want my parallel app to fall apart on certain platforms.
I personnaly use Visual Studio to build my code on Windows and other compilers to build the same code on other platforms (Mac, Linux, Android...).
To be sure you don't get locked with Windows, make sure (at least, it's not exhaustive):
You don't use any win32 API (prefer cross plateforme libraries like boost for instance for network, file system access...)
You don't use 3rd party libraries only available for Windows
Don't use CString, or anyother Microsoft class. Prefer STL.
Be careful with file system case sensitiveness too! (#include "Foo.h" while file is "foo.h" on disk will work on PC, not under Mac/Linux). Prefer naming ALL your files in lower case.
...
You may want to have a look at CMake. This tool can help you generating compilation project file for the same source to be compiled on different plateform. Then, you can generate vcproj/sln files to compile your code with Visual Studio on Windows, MakeFile(s) to compile it under Linux and XCode project files to compile it under MacOS. If somewone wants to compile you code under Windows with another compiler than Microsoft, it's also possible!
Also note that recent version of VS (2015) propose to compile for other targets that Windows (at least Android). But never tried that.
The compiler itself is pretty standard confroming by know (if you turn off the extensions) and more importantly, you can use the clang frontend (which is the default compiler on Mac) directly from within VS2015, so it is definitvely possible to write cross-platform code in VS (although it's certainly easier to use Windows specific constructs than it where if you'd use e.g. cygwin).
However, the windows API for network I/O is different from the one for Mac, so you should probably use a corssplatform library like boost asio for that.
As far as multithreading is concerned, you can do it in a standard and portable manner using the standard library's functions, classes and synchronization primitives, but the past has shown that they are often not the most efficient way to go. However, in most situations you'll want to use a more highlevel library for parallel programming anyway. The default on Windows is the PPL which is - I believe - not cross-platform, but there are other libraries you can use
Finally, you can use VS to remotely build your applications on Mac or Linux PCs using their local compilers and libraries. However, I don'T know, how well that works in practice.
Some open source projects explicitly state that in order to compile on windows, they need a microsoft compiler (often a specific version as well, as latter versions are incompatible or will refuse to compile older code).
Since it seems absurd to me that, since there are foss compilers that can compile for windows, a microsoft compiler would be necessary for any fundamental task, I'm assuming this is because those projects use api calls to libraries (such as msvcrt*.dll) that, for some reason, mingw-gcc, clang and other ports of compilers for windows are unable to compile against.
My understanding of these requirements is shallow, since my experience with compiled code comes primarily from linux and this worries me, since getting a microsoft compiler is non-trivial. the only way to get them is through the express editions of microsoft's visual c++, and even then, the most recent version will completely refuse to install on an old winxp machine like mine and the only version available at the moment is vc++express2010, which requires registrations to turn from trialware into freeware (and even then i'm not clear on if that'll work or what it entails - perhaps OS hooks to "debug" and other intereference?).
1) My question is, do these projects depend on microsoft compilers due to building against these microsoft-only libraries (which apparently foss compilers can't do)?
It would seem absurd if the reason is the build script or preprocessor directives, since those can be relatively easily ported.
2) Also, is it possible that, even if I avoid any msvcrt/.net/etc. calls, i can still find myself needing a microsoft compiler to compile native windows software (assuming no usage of libraries that do perform those calls)?
3) Can I simply use clang and some widget library to make native windows software just as well?
4) Can I modify the source of a project so that it doesn't depend on a microsoft compiler?
(ok that's 4 questions, sorry, this is quite hard for me to express clearly).
1) My question is, do these projects depend on microsoft compilers due
to building against these microsoft-only libraries (which apparently
foss compilers can't do)?
Compiler vendors and GUI framework vendors can supply DLLs that perform similar to the MS DLLs. Some of the MS DLLs are system DLLs and are used by the other compiler and framework vendors.
If you are using compiler or framework specific DLLs, they need to accompany the installation of your programs (projects).
2) Also, is it possible that, even if I avoid any msvcrt/.net/etc.
calls, i can still find myself needing a microsoft compiler to compile
native windows software (assuming no usage of libraries that do
perform those calls)?
No. If you scan through the posts on StackOverflow, there are many people who are using the Windows API directly, I guess what you are calling native windows software. Usually, the code for these API are located in a system API. The compiler translates the function call to a call into these DLLs, loading them as necessary.
3) Can I simply use clang and some widget library to make native
windows software just as well?
No, you can't. That's why they exist.
Again, many people are using frameworks like Qt and xWidgets without the MS compilers. I did that for a while. I switched over to Visual Studio, primarily for the debugger. I didn't like how other IDEs tried to use GDB. Otherwise, I wouldn't use MS because they tend to go by the Microsoft Standard language rather than the ISO.
4) Can I modify the source of a project so that it doesn't depend on a
microsoft compiler?
No, that is why there are freeware and other compilers out there.
Hmmm, one can use Java to create GUIs that don't use the MS compiler, but they use the Windows API.
Try installing Cygwin. When you look at all the libraries you will realize that projects can be created that don't use the MS Compiler. Again, read through the StackOverflow posts and you will find that people are using other compilers, such as Intel, GNU, Clang, Greenhills and others. Some compilers for embedded systems will also compile for Windows OS, so you can write code that works on both platforms.
Looks like you need to search the web for "GNU GUI tutorial C++" and see what pops up. Also, search for "wxWidgets" and "Qt" for other frameworks.
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 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.