RE: [boost] Re: Boost Jam question: how to set "features"?

From: Steve Anichini (sanichin_at_[hidden])
Date: 2001-11-09 10:40:14

> From: williamkempf_at_[hidden] [mailto:williamkempf_at_[hidden]]
> --- 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.
>

You are confusing the issue. We aren't discussing whether boost libraries
can be DLLs or not. I have no problem with Boost.Threads being a DLL. My
issue is not allowing the option of building boost to link with the STATIC
C-Runtime.

> 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.
>

"Install the latest SP" is NOT a valid response to your customers! Let me
give you some background - I'm just coming from a PC programming job doing
games programming. Game consumers want their games to work out of the box.
Games are expected to install everything they need in order to run (DirectX,
etc). Our publisher would have NEVER let the game ship if our solution to a
particular DLL conflict was "install the latest service pack." (Our game was
held up for two weeks do to installer issues - particularly, getting the
DLL/COM redirection stuff in the installer to meet Windows Logo
requirements. Just to give you an example of how seriously some companies
take this stuff.)

> 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.

Well, if you want boost to be used by anyone on Windows, you should start
paying attention to MFC. A lot of Windows developers use MFC. Yes, boost
doesn't use MFC, but it should play well with MFC - both the static linked
version and the DLL version.

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

Tell that to me and my product team who had to ship a game not too long ago
that would run out of the box on Windows 95A. Not all companies have the
same support policies as MS - just because Microsoft isn't supporting pre-98
(and by the way, Windows 98, the original edition, does not handle DLL/COM
redirection), doesn't mean that no one else is. I'm sure there are some
companies out there still actively supporting their DOS and Windows 3.1
products.

> 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.

Your installer requirements are not as stringent as others. The installer I
had to write had to meet strict guidelines as far as replacing/installing
system DLLs such as mscrt.dll. It required that different things happen on
different flavors of Windows.

Just because you haven't had these problems, doesn't mean other people
won't. I'm just suggesting the OPTION of building boost linking to the
static runtime. The default can remain the way it is.

-steve