Re: [boost] [filesystem] Major changes before standardization

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-11-15 05:29:03

Beman Dawes wrote:
> At 03:11 PM 11/14/2004, Peter Dimov wrote:
>> 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 users 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
> http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdkredist.htm?
> or provide the redestributables in an apps installer if it has one?

It might be acceptable to require applications to ship unicows.dll. But then 
again, we don't require pthreads-win32.dll, we decided to reinvent the 
wheel. :-)

> Even if we provided an alternate implementation that considered Win9X to 
> have char based native path strings, we still have to do conversions
> between  strings and wstrings; filesystem::path traffics in either
> regardless of the native platform. Since the default conversion has to be 
> the one provided by the operating system if any, we still can't get away 
> from needing the Microsoft Layer for Unicode on Win9X.

We ought to be able to duplicate the MSLU behavior by using 
WideCharToMultiByte. But MSLU presence is not the main issue here. The main 
issue is the native character type, which is not wchar_t on Windows 9x, even 
with MSLU installed.

> The idea that the default conversion has to be the one provided by the
> operating system (if the O/S supports conversion between wide and
> narrow character paths) isn't something that I invented. It has been
> mentioned by a number of the developers with actual wide/narrow experience 
> that
> I've asked for advise over the last couple of years.  I can think of two
> committee members (not from the same company, either) who were really
> adamant about it.

I don't understand this paragraph. Choosing the wrong native character type 
causes redundant roundtrip conversions, one in Boost.Filesystem, one in the 
OS (or the MSLU add-on, which is not part of the OS, BTW.) I don't see what 
the reasonable opinions of the two committee members have to do with that. 
FWIW, I've repeatedly expressed the same opinion.