Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-11-09 14:02:49

--- In boost_at_y..., "Steve Anichini" <sanichin_at_2...> wrote:
> > From: williamkempf_at_h... [mailto:williamkempf_at_h...]
> > --- In boost_at_y..., "Steve Anichini" <sanichin_at_2...> wrote:
> > > I can't think of any reason a library should require linking to
> > DLL C
> > > runtime instead of the LIB C runtime.
> >
> > Then you aren't thinking hard enough ;). Boost.Threads *must* be
> > 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
> can be DLLs or not. I have no problem with Boost.Threads being a
> issue is not allowing the option of building boost to link with the
> C-Runtime.

No, I'm not confusing the issue, though I didn't fully explain
either. Generally, DLLs must be linked to the DLL version of the
RTL. There are numerous reasons for this, such as memory issues, TLS
management issues, etc.

> > The need for distributing the C RTL DLL is diminishing to the
> > 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!

I disagree. If the problem is in the OS and they call MS that's the
response they'll get. msvcrt.dll is, for all intents and purposes,
part of the OS.

> 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
> 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
> take this stuff.)

You're complicating things too much I think. Standard response to
this issue for all applications I've run across is simply to have the
installation package warn that SP X is required and ask if they want
it to be installed, spawning the MS supplied install package if they
say yes.

Regardless, I still don't see this as a Boost issue in general.
> > MFC is a different matter, but Boost doesn't directly use MFC and
> > think it at least a little unreasonable to expect MFC to affect
> > 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
> paying attention to MFC.

Again, I don't agree, and I am a Windows developer by trade (and
specifically use MFC for 90% of my development).

> > 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
> redirection), doesn't mean that no one else is. I'm sure there are
> companies out there still actively supporting their DOS and Windows
> products.

Yes, that's true, but the issues for supporting such systems go
beyond what you should expect Boost to do for you. It's difficult
enough making this stuff portable to the current platforms. If you
want support for legacy platforms you're likely to have to do some of
the leg work yourself. The developers I'm sure would be happy to
incorporate your changes once you've done that work.
> > 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
> > However, these DLLs have been stable for so many years that it's
> > really an issue either, even ignoring that most (all?) supported
> > 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.

You're guessing here. Actually, our installer requirements are much
more stringent then most. We do have the "luxury" of telling our
clients we don't support any platform not supported by MS, but beyond
that our requirements are not likely any less stringent than yours.

> The installer I
> had to write had to meet strict guidelines as far as
> system DLLs such as mscrt.dll. It required that different things
happen on
> different flavors of Windows.

That's why MS provides Installation solutions for the system DLLs.

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

Remember that Boost is a *collection* of libraries. Not all
libraries have any link requirements since they are nothing more than
template code in a header file. Other's have strict linkage
requirements. Other's should probably offer multiple linkage
patterns, but I don't know if any of the current ones fall into this
category or not. I know that Boost.Threads does not.

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at