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

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

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

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

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

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

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

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 
replacing/installing
> 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 
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.

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