From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-11-14 17:47:04
Beman Dawes wrote:
> At 03:11 PM 11/14/2004, Peter Dimov wrote:
> >Beman Dawes wrote:
> >> I've been assuming Microsoft's Layer for Unicode, and was assuming that
> >> Peter meant there were serious problems even if it was enabled.
> >No, MSLU works, as far as I know. But we can't assume its existence. A
> >library that doesn't support Win9x without MSLU will not be useful for
> >that need to write code that works on a wide variety of machines. Win9x's
> >installed base, although declining, is still significant.
> Is there a reason not to just point such users to
> or provide the redestributables in an apps installer if it has one?
While this isn't an issue to me personally, there are a great number of
users for which MSLU is unacceptable. For whatever reason, MSLU has
rather stringent redistribution terms that are significantly more strict
than the BSL, and mutually incompatible with many open source licenses,
including the GPL.
I would recommend avoiding using MSLU if possible because it will stymie
adoption of the library by certain catagories of users, and will
possibly cause unintentional infringement or misunderstanding. It also
undermines the intentions of the BSL.
Due to these problems, at least one project has attempted to reimplement
MSLU under a more friendly license, such as the so-far incomplete MZLU
from Mozilla. The open source libunicows replaces Microsoft's
pseudoimport library, and will dynamically use with MSLU or MZLU,
depending on what is availible at load time.
However, if only a small number of functions are needed, which I suspect
would be the case, it might be best to eliminate this problematic
dependency entirely, and dynamically resolve the wide functions as
needed, using appropriate fallback functionality if they are
unavailible. The functionality could probably be encapsulated
transparently within some sort of helper class.
Aaron W. LaFramboise
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk