Re: Boost Jam question: how to set "features"?

From: williamkempf_at_[hidden]
Date: 2001-11-09 10:21:00

--- In boost_at_y..., "Steve Anichini" <sanichin_at_2...> wrote:
> I can't think of any reason a library should require linking to the 
DLL C
> runtime instead of the LIB C runtime.

Then you aren't thinking hard enough ;).  Boost.Threads *must* be a 
DLL in order to manage thread TLS cleanup (and this means dynamic 
linking to the RTL).  There are several other reasons that could 
require this as well.

> For some applications, linking to the static version of the runtime 
makes
> more sense. For example, with static linking one doesn't have to
> redistribute the C runtime (msvcrt.dll) with your app. Even though 
some
> version of msvcrt.dll ships with all Win9x and WinNT systems, it's 
not
> necessarily the version you need if you need one with a bug fix 
from one of
> the VC6 service packs. Also, if you are using MFC and linking to 
the DLL,
> you have to distribute the MFC DLL as well for the same reason.

The need for distributing the C RTL DLL is diminishing to the point 
of nearly not being an issue.  The msvcrt.dll exists on all MS 
supported platforms.  If there's a bug in an older version the 
response simply is "install the latest SP" because of this.

MFC is a different matter, but Boost doesn't directly use MFC and I 
think it at least a little unreasonable to expect MFC to affect the 
technical decisions made for Boost libraries.  In any event, there 
are simply times that you have no choice on this subject.

> Yes, static linking produced larger executables. But it also is an 
easy path
> to know exactly what version of the C-runtime and MFC you are using.
> Otherwise you can find yourself in DLL hell, and supported 
mechanisms to
> cope with multiple DLL versions didn't really exist until Windows 
98 Second
> Edition/Win2K:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/sbscs/sideb
> yside_2l2r.asp
> Windows XP introduces a better mechanism, but not everyone lives in 
a world
> where they can ignore NT 4, or Pre-98 Second Edition Win9x.

Pre-98 will no longer be supported by MS after next month, so it 
shouldn't be an issue for you either.  I believe NT 4 supports the 
concepts you're discussing starting with SP 5, though someone will 
correct me if I'm wrong.  However, even NT 4 is on the radar scope 
for being dropped from support by MS within the first half of next 
year (the same is true of 98).
 
> If you still don't believe me, try writing a production-quality 
installer
> that deals with DLL/COM redirection and you will realize the pain 
that it
> can cause! It's a very difficult thing to get right.

We install several applications today using several (over 30) DLLs 
and experience no DLL hell.  All application DLLs get installed in 
the same directory as the application's executable eliminating any 
chance for DLL hell from anything other than the MFC and C RTL DLLs.  
However, these DLLs have been stable for so many years that it's not 
really an issue either, even ignoring that most (all?) supported OSes 
allow you to drop these DLLs in your application directory as well if 
you truly find it an issue.

Bill Kempf