using MSVCRT.DLL instead of MSVCR71.DLL

[Baga]

Our product is compiled with /MD switch, so it uses
MSVCRT.DLL But as every system configuration that we
support includes this file anyway, we do not actually
redistribute it, instead we use the one which is already
present.

However, when we compile with /MD switch on .NET 2003,
MSVCR71.DLL is used instead, and it is not required to be
present in system already. This means, that if we switch
to .NET, we will have to redistribute MSVCR71.DLL and
MSVCP71.dll (which we don't use at all, but somehow it
sneaked in)

Does anybody know if it is possible to trick .NET 2003 to
use old MSVCRT.DLL instead? This is one of the strongest
arguments against .NET...

-- Thanks.

 

[Baga]

Well, we require IE 5.x or later, that limits number of
possible versions of MSVCRT.DLL. At least we newer run
into any problems related to MSVCRT.DLL.

Anyway, thanks for the great (and prompt) advice! I knew
there should be some simple solution... I'll try it ASAP
and post how it worked out...

-- Baga

 

[Doug Forster]

Hi,

Have you tried the static library option. You might be surprised at how
little the size difference is.

Cheers

Doug Forster

 

[Ronald Laeremans [MSFT]]

This is a bad, BAD, BAD, BAD option. Compiler features like the /Gs security
checks depend critically on the new CRT. And that is apart from the fact
that you just threw out the benefits of several tens of person years of QA
by using an entirely untested and unsupported configuration.

Linking statically if for some reason you cannot distribute the DLL version
of the runtime is definitely a far superior option here.

Ronald Laeremans
Visual C++ team

 

[Baga]

I admit, switching runtime library under compiler's foot
is not exactly nice and solid solution, but it would not
scare me away if it worked... Unfortunately it does not. I
got couple symbols undefined during link - _ftol2,
_security_cookie or something like that... Compiling
statically didn't work either - lots of link error for
some reason. Finally we decided that few benefits
which .NET offers to existing unmanaged code do not pay
for the pain it causes, and decided to stay with VC6. At
lest VC6 compiles 2.5 times faster...

BTW, i found compiler bug in .NET, if i can isolate it, i
will post it here.

Anyway, thanks to all for your concern and replies,
-- Baga