Why do programs written in VC++ require runtime library to run?

[winterslam]

Even a 'hello word' program requires MSVCR**.dll
I thought VS was supposed to compile projects to native code.


Then how are those programs supposed run on other platforms?

[GamerMax5]

err... Did you read up on exactly how the MSVC compiler works?

The compiler is specific to the Windows platform. The code may be written in C++ but is still compiled using the Microsoft compiler. If you're looking to run the code on other platforms, then you can just copy the actual *.cpp or *.hpp files and compile them on other platforms using other compilers so long as you wrote the files with native ANSI C++ and didn't use managed C++ which is Windows-exclusive.

Last time I checked, Microsoft wasn't too keen about any of their products being cross-platform.

[01010011]

err... Did you read up on exactly how the MSVC compiler works?

The compiler is specific to the Windows platform. The code may be written in C++ but is still compiled using the Microsoft compiler. If you're looking to run the code on other platforms, then you can just copy the actual *.cpp or *.hpp files and compile them on other platforms using other compilers so long as you wrote the files with native ANSI C++ and didn't use managed C++ which is Windows-exclusive.

Last time I checked, Microsoft wasn't too keen about any of their products being cross-platform.

This reply was really helpful to me GamerMax5, thank you.

[winterslam]

err... Did you read up on exactly how the MSVC compiler works?

The compiler is specific to the Windows platform. The code may be written in C++ but is still compiled using the Microsoft compiler. If you're looking to run the code on other platforms, then you can just copy the actual *.cpp or *.hpp files and compile them on other platforms using other compilers so long as you wrote the files with native ANSI C++ and didn't use managed C++ which is Windows-exclusive.

Last time I checked, Microsoft wasn't too keen about any of their products being cross-platform.

Where can I read up how the MSVC works?

Anyway MSVC is rather pathetic then

[GamerMax5]

Where can I read up how the MSVC works?

Anyway MSVC is rather pathetic then

I hate to use this answer but really if you Google "Microsoft Visual C++ Compiler" or "MSVC++ Compiler" you can find websites that contain some information about how the compiler works. Personally, I used Wikipedia, MSDN, and the Visual C++ Language Specification (ECMA Standard 372).

I don't think you can really say that MSVC is pathetic. In the context of RAD for Windows, it really performs great if C++/CLI is a part of your toolbox. MSVC, from the start, was never intended for cross-platform compatibility (Windows-versions yes, Windows to *NIX no), especially if you write your Windows programs with CLI which is Windows-exclusive. But if cross-platform compatibility is a concern, there are other compilers available for Windows that are pure C++ native (MinGW, DJCPP, etc...) and there are IDE's available for those compilers (Dev-C++, Code::Blocks, etc...). They're not as full featured as the MSVC IDE and no where near as nice looking but they get the job done.

[wey97]

Couldn't he link statically?

[GamerMax5]

I've never been keen on static linking. From what I've seen, it's nice if you want to ensure that all third-party libraries that your program uses run appropriately on computers that don't feature the actual code or run-times. But I've had problems when the time comes for an update for one of the underlying libraries that were statically linked. You can't just ship the updated library because a static link bundles everything into one executable. You end up having to recompile the entire project and ship it back out instead of just updating one portion of the program.

As far as static linking a MSVC project and trying to run it on a *NIX environment, I haven't tried it. If it's a project written with native C++ then I wouldn't think it would be too much of an issue but if you write a Windows GUI or Windows Console project using CLI then I think you may have some problems even with a static link.

CLI relies on the .NET Framework so I would imagine that you may have some leverage with a *NIX environment if you're running Mono or Wine but don't quote me on that.

I think I may give it a shot sometime soon when I have some free time.

[wey97]

Absolutely. I would never want to link statically unless I was certain any libraries would never be updated. I was just suggesting an option if OP hated dynamic linking. It's a necessary evil (or not evil) depending on how you look at it.

Beginners usually struggle with the concept or are shocked by the size of the runtime. Realize that it streamlines patching so if everytime MS updates even one line of code, the whole runtime doesn't need to be linked back in and the full executable redeployed. A small patch can be released.

Since it's been brought up, I've never found a good way to package the Visual C++ runtime in an installer to make sure it's installed before the executable is run. Other than stating in the installation instructions that the runtime needs to be installed first (which it may already be installed) or that if the message "XX.dll is missing" appears, install the runtime. Neither of those options are appealing.

[GamerMax5]

Since it's been brought up, I've never found a good way to package the Visual C++ runtime in an installer to make sure it's installed before the executable is run.

Well that's why I prefer to just keep MSVC compiled programs within a Windows environment. Most of what I write relies upon the .NET Framework anyway so as long as you have the framework runtimes installed on your computer, as any proper Windows user should have, you don't have to worry about the application not running. Also, if I'm not mistaken, Microsoft pushes the Visual C++ Runtime as an update available through Windows Update. And some programs actually install the runtime on your computer like Sony's MediaGo for PSP or PS3 users.

I used to see that xx.dll is missing error more often back when I was writing apps in VB6 and deploying them in larger-scale environments that had a varying range of computers.