VS2005 C++... about the runtime library

D619d95cddb1edb227f51ef539d15cdc
0
Nautilus 103 Jan 17, 2007 at 16:04

I was about to post a question, but it was answered already in this other thread.

I still have a curiosity…
If I stick to C++ (using VS2005), can I force the compiler to build for the msvcrt60.dll instead of msvcrt80.dll?

Regards,
Ciao ciao : )

13 Replies

Please log in or register to post a reply.

A8433b04cb41dd57113740b779f61acb
0
Reedbeta 167 Jan 17, 2007 at 16:20

I believe you can add msvcrt60 to the linker inputs, and check an option “ignore default libraries” or something of the sort to prevent automatically linking with the 8.0 version of the runtime library.

D619d95cddb1edb227f51ef539d15cdc
0
Nautilus 103 Jan 17, 2007 at 18:44

I tried what you suggested.
Either it can’t work, or I couldn’t do it right :blush:

Yet another big headache was on its way… v_v#

But then I used your suggestion to reformulate my query in google.
So I came across a webpage suggesting a neat thing: use the /MT option, instead of /MD, which will statically link to the runtime.

In this way the compiled exe won’t look for the DLL to link to at run-time, but it’ll use its own copy of it, incorporated at compile time.

The cons of this method are 2:
1) the final compiled exe is bigger than normal;
2) in case of a multi-project solution, all of the projects have to be compiled with /MT.

The pro is: the program is sure to run on any Win OS, no matter what runtime is available.

Thanks for your time,
Ciao ciao : )

340bf64ac6abda6e40f7e860279823cb
0
_oisyn 101 Jan 17, 2007 at 19:46

No, you can’t. It may work for functions like strcmp and the like, but I believe the C++ name manging has changed (so no std::iostream functions, for example), and there are a lot of support routines in there which you don’t call directly but the compiler generates when using certain language constructs (when you throw an exception, for instance).

But I still don’t understand why you need to link with the 6.0 version? msvcrt60.dll has to be distributed with your applications as well (you can’t really count on the fact that the dll is already there), so you’ll have exactly the same problems as with the 8.0 version.

D619d95cddb1edb227f51ef539d15cdc
0
Nautilus 103 Jan 18, 2007 at 00:05

@.oisyn

[…] But I still don’t understand why you need to link with the 6.0 version? […]

There is no why, in fact. I don’t need to do it.
But I was curious to know of a way to NOT force the target system to have a copy of the runtime installed.
Kind of to keep things clean, since I like to *infest* the target system the least possible.

At first I thought the ideal would be to specifically build for the older runtime (version 6.0, being the most widely spread), but then a better solution was found.

Ciao ciao : )

6d318bb67270aa12b325e2cd7b64ff7a
0
pater 101 Jan 18, 2007 at 21:05

To avoid “infesting” a target system, you can just copy the msvcrt (whatever version you need) to your applications directory, instead of the windows folder. This is nowadays even the preferred way of installing libraries. (Although, for something that common as an VC runtime lib, this is kind of a waste of disk space IMHO)

D619d95cddb1edb227f51ef539d15cdc
0
Nautilus 103 Jan 19, 2007 at 02:23

Hello,
what if I want a one-file program: just the executable?
Also, the runtime version 8.0 is not at all that common on a Win98, or a Win2K, or even a WinXP.

Personally, I love the small utilities that you just copy somewhere, double-click and they simply run.
No installs, no reboots, no additional components required.

Ciao ciao : )

6b7e1a4b42e4b47d92fdef8bf2bd8e2c
0
Jare 101 Jan 19, 2007 at 03:23

@pater

To avoid “infesting” a target system, you can just copy the msvcrt (whatever version you need) to your applications directory, instead of the windows folder. This is nowadays even the preferred way of installing libraries.

It’s not that simple: http://www.codeproject.com/cpp/vcredists_x86.asp

6d318bb67270aa12b325e2cd7b64ff7a
0
pater 101 Jan 19, 2007 at 09:54

@Jare

It’s not that simple: http://www.codeproject.com/cpp/vcredists_x86.asp

Oh, damn…. :sad:
That’ll give me some headaches when porting our application to VS2005 (we didn’t do so yet). Thanks for the hint. :surrender

340bf64ac6abda6e40f7e860279823cb
0
_oisyn 101 Jan 19, 2007 at 10:47

So what have we learned: just link with the darned static library, and use a tool like UPX to minimize the size of your executable ;)

D619d95cddb1edb227f51ef539d15cdc
0
Nautilus 103 Jan 19, 2007 at 14:08

And I confirm that linking statically does work.

For the sake of testing, no more than 20 minutes ago I have compiled a program (with VS2005) in two versions (/MD and /MT) and copied both executables on a Win98SE freshly installed.

/MD version complained that the DLL wasn’t found, as expected.
/MT version, instead, did run flawlessly.

Ciao ciao : )

340bf64ac6abda6e40f7e860279823cb
0
_oisyn 101 Jan 19, 2007 at 16:09

Can you also post the sizes of your executables? ;)

D619d95cddb1edb227f51ef539d15cdc
0
Nautilus 103 Jan 19, 2007 at 18:04

Sure.

/MDd (debug config, dynamic link, no optimizations) : 184 KB
/MTd (debug config, static link, no optimizations)  : 576 KB

/MD (release config, dynamic link, speed optimization) : 92 KB
/MT (release config, static link, speed optimization)  : 136 KB

In all 4 cases, the program carries 22.1 KB of image resources,
that is: 2 icons and 1 [80 x 80 x 8bpp] bitmap.

EDIT: Plus a VERSION_INFO block and 8 Dialogs.
No MFC used, only Win32 API.

Ciao ciao : )

B91eae75cd6245bd8074bd0c3f1cc495
0
Nils_Pipenbrinck 101 Jan 19, 2007 at 20:54

go for the static link.. Who cares about 44kb of memory these days..