13 replies to this topic

[Nautilus]

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 : )

[Reedbeta]

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.

[Nautilus]

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 : )

[.oisyn]

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.

[Nautilus]

.oisyn said:

[...] 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 : )

[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. (Although, for something that common as an VC runtime lib, this is kind of a waste of disk space IMHO)

[Nautilus]

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 : )

[Jare]

pater said:

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.codeproje...redists_x86.asp

[pater]

Jare said:

It's not that simple: http://www.codeproje...redists_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

[.oisyn]

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

[Nautilus]

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 : )

[.oisyn]

Can you also post the sizes of your executables?

[Nautilus]

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 : )

[Nils Pipenbrinck]

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