By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,308 Members | 1,460 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,308 IT Pros & Developers. It's quick & easy.

using MSVCRT.DLL instead of MSVCR71.DLL

P: n/a
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.
Nov 16 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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

Nov 16 '05 #2

P: n/a
Hi,

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

Cheers

Doug Forster

"Baga" <us********@yahoo.com> wrote in message
news:03****************************@phx.gbl...
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

Nov 16 '05 #3

P: n/a
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" <us********@yahoo.com> wrote in message
news:03****************************@phx.gbl...
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

Nov 16 '05 #4

P: n/a
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
-----Original Message-----
This is a bad, BAD, BAD, BAD option. Compiler features like the /Gs securitychecks depend critically on the new CRT. And that is apart from the factthat you just threw out the benefits of several tens of person years of QAby using an entirely untested and unsupported configuration.
Linking statically if for some reason you cannot distribute the DLL versionof the runtime is definitely a far superior option here.

Ronald Laeremans
Visual C++ team

"Baga" <us********@yahoo.com> wrote in message
news:03****************************@phx.gbl...
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


Nov 16 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.