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

From: Steve Anichini (sanichin_at_[hidden])
Date: 2001-11-10 13:42:54

From http://support.microsoft.com/support/kb/articles/q140/5/84.asp

"A reusable library and all of its users should use the same CRT library
types and therefore the same compiler switch. The macros defined (or not
defined) for each of the compiler switches can be used in the header file(s)
of your reusable library to enforce the proper compiler switch. The sample
code in this article demonstrates how to use these macros.

If you would like users of the library to be able to choose static or DLL
CRT, you should provide both static and DLL reusable library types."

Also read http://support.microsoft.com/support/kb/articles/Q190/7/99.ASP

Notice that using the DLL runtime will not solve the "passing a FILE handle
across DLL/EXE boundaries" problem in all cases. If someone's app is using
the static CRT and your DLL is using the DLL crt, things will still bomb
passing CRT objects across the DLL/EXE boundary.

The solution is to not cross CRT stuff across the DLL/EXE boundary. The
general rules of thumb for passing dynamically allocated stuff from/to DLLs:
        1) Something allocated on the EXE side must be freed on the EXE side and
the same for on the DLL side
        2) You can pass objects safely with VC6 if they define a virtual
destructor. The compiler will generate the correct call of delete using the
correct run-time library.
        3) You can also pass objects by overloading new and delete for the object
if its defined in the DLL - the DLL runtime will be used.

Basically making your DLL designs dependent on forcing everyone to use the
DLL version of the runtime is a potentially dangerous decision that will
just cause more grief than it will solve.

My main points:
        1) there is no One Right Answer for choice of runtime used in
applications - be it static or DLL.
        2) therefore boost libraries should strive to be designed in such a way to
support usage with both runtime types.
        3) I see nothing in your threadmon.cpp code that requires the multithreaded
DLL version. You are not passing CRT stuff or any memory allocations across
DLL boundaries. Yes the static version will cause another copy of the CRT,
but that is just a code size issue, not a code correctness issue. Such a
decision is best left to application developers.

So my question is what specific thing is threadmon doing that you think
requires the DLL version of the runtime?

I feel so strongly about this issue. I find when libraries take a "Library
Knows Best" attitude about this kind of stuff it really limits their
usefulness. Runtime version policy is best left up to the application,
because it has more knowledge about its domain. Only when the library can
not be made to work with other versions should this policy be enforced by
the library. I have not been convinced that the threadmon DLL requires the
DLL version of the runtime.

I'll give you an example of the kind of frustration this stuff has caused me
in the past.

1) I'm going along merrily making my application with the dynamic version of
the runtime.
2) I want to use a third party library that comes without source. They only
provide a version linked to the static runtime.
3) Now I have to change my entire app over to the static runtime because
some library designer didn't provide both versions of the library.
4) Things can get worse when you have multiple libraries all making the
"runtime version" choice for you. If you don't have source code to these
libraries, it can cause a lot of headaches, resorting to /NODEFAULTLIB
linker switches, and wondering if your app is eventually going to blow up
from all these mixed CRTs.

-steve

> -----Original Message-----
> From: williamkempf_at_[hidden] [mailto:williamkempf_at_[hidden]]
> Sent: Friday, November 09, 2001 1:03 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Boost Jam question: how to set "features"?
>
>
> --- 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
>
>
> Info: http://www.boost.org  Unsubscribe:
> <mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>