Re: [boost] DLL names under windows

From: Carl Daniel (cpdaniel_at_[hidden])
Date: 2001-10-22 12:04:49

----- Original Message -----
From: "David Abrahams" <david.abrahams_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, October 22, 2001 9:43 AM
Subject: Re: [boost] DLL names under windows

> So, does this get the build system off the hook, or is there still an issue
> to address?
>
> If there is, somebody PLEASE post a proposal for how things should work,
> with some reasonable amount of detail. I can make the build system do almost
> anything, but I need to understand the requirements first. I am not an
> expert in the domain of DLL conflicts and naming.

It's easy to be an expert in DLL conflicts: if two DLLs weren't built by identical build environments, it's safe to
assume that they're incompatible.  If the DLLs expose C++ classes, that'll be nearly 100% accurate.  For DLLs with 'C'
APIs, it is possible for them to be compatible across several implementations (it's almost guaranteed - every
implementation needs to be able to use Kernel32.dll, which uses MSFT Naming/calling convention for C).

As Ed Brey responded, dumping DLLs in the Windows System directory has been taboo for many years, although it's still a
common enough practice.

Given the number of binary incompatible implementations of C++ under Windows (MSVC, Borland, MWCW, GCC/Cygwin, ...), it
probably makes sense to encode the development platform into the names of any DLLs which are produced.

Here's an example from the past:  Rogue Wave Tools.h++ used the following naming convention:

CtlMWGT.lib  (.dll)

where - lower case letters are as-is

C code the compiler
    b3 - Borland C++ 3.x
    h - Metaware High-C
    ...

M - Memory model
    ... fortunately, this is relevant anymore

W - Windows/DOS format.  Really, they used this to encode whether a lib was a static lib or a DLL import lib.
    (absent) - DOS static import library.  This isn't relevant, but the other two could be.
    d - dll import library
    w - windows static library

G - Codes whether library is a debug build
    (absent) - not a debug build
    g - debug build

T - codes whether library is a thread-safe build
    (absent) - single threaded
    mt - multi-threaded

Within MSFTs DLL's, it's customary for debug builds to have names ending in D.

IMO, information like that which Rogue Wave encoded in their C, W, G and T fields is still useful and could avoid
unpleasant incompatibilities when (not if) people dump Boost DLLs into Windows/System32.

I will confess to have not attempted a Boost build with any system, but I was a bit surprised from the original post
that started this thread:  I wouldn't expect (or want) Boost::Regexp to produce ANY DLLs at all.  I hope that the build
process can produce static libs in addition/instead of DLLs for all of Boost.

-cd