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

[Mohan Embar]

Hi Andrew,

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

On a related note, is there any way of adding additional Win32-specific
files containing general-purpose classes which can be reused across nat*.cc
implementations? For example, say I wanted to have an IWin32 interface
(remember: don't pay attention to my names) and a Win9X and WinNT implementations.
I'd love to give these their own header and .cc files, but current
practice dictates we put this into the monolithic win32.h and win32.cc
files. Is there some configury trick that would make my approach possible
without inconveniencing the non-Win32 folks?

>The problem is that SWT maps *foo onto int.  So, many Java methods are
>passed ints, but there's no type checking -- all that you know is
>you're passed a pointer to something, and you pass that to a native
>method.  All the type checking we've grown to love has gone.

But is there anyway around this, given that you're forced to use JNI
outside of the gcj world? The thing that dazzled me about the SWT OS
wrapper approach is that I can step through my OS calls directly in the
Java debugger. I understand that there's a loss of type safety with some
of the mappings, but when I compare that to the hell I had to go through
trying to convince MS Visual Studio to fire up an instance of IBM Visual
Age in order to debug my JNI DLL, I was dancing on the tables when I read
about that approach.

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