Patch: New version of "UTF-16 to 'Win32 locale' conversions" and filenames (replacing convertion tables with Win32 API calls)

[Andrew Haley]

Mohan Embar writes:
 > >
 > >Since MultiByteToWideChar()/WideCharToMultiByte() functions are also 
 > >available in NT/2000/XP, I cannot find any reason to loose time with a 
 > >temporary patch using a C++ interface. Therefore I shall only propose a 
 > >temporary patch for GCC 3.4, using A-functions.
 > 
 > There is one inherent problem with this approach on Windows. WinNT
 > and above supports UNICODE natively. Win9X does not. And WinNT does
 > everything internally in UNICODE. When you call the A functions on
 > WinNT, the OS will first convert the string to UNICODE before
 > calling the W function. All A calls on WinNT (which also means
 > Win2K, WinXP, etc.) are therefore inherently more inefficient than
 > their corresponding W calls.
 > 
 > If we unconditionally implement the
 > MultiByteToWideChar()/WideCharToMultiByte() approach on WinNT, then
 > we will be converting from UNICODE to ANSI and back to UNICODE
 > again. This seems unnecessarily wasteful, especially since the sole
 > reason for doing this is pandering to the Win9X OSes which are
 > essentially obsolete. I'd much rather use the W functions directly
 > on WinNT platforms, which we already know that we can't do on Win9X
 > without Unicows, which I agree that I'm ambivalent
 > about. Therefore, I don't see any way around a dual code base on
 > Windows even with Bryce's proposal.

To what extent is this really worth worrying about?  Make it work
first, optimize later.

 > >The same kind of approach has been taken for SWT (see OS.java in 
 > >org.eclipse.internal.win32).
 > 
 > SWT simply implements one-to-one Java wrappers around the corresponding
 > OS call.

Yes it does, and having done a lot of work on SWT I'm not convinced
it's a model to follow.

Andrew.