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

[Mohan Embar]

Hi Andrew,

> > 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.

We're talking a C++ interface with two braindead implementations: one which
reads really nicely because it's essentially a passthrough, and another more
slightly convoluted one which we can eventually throw out. This seems
like a worthwhile investment to me.

> > 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.

Could you elaborate on this more?

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/