RE: [Openexr-devel] UNICODE support in openexr file I/O

[Luc-Eric Rousseau]

> -----Original Message-----
> From: Drew Hess 
> 
> I (and, I'm pretty sure, Florian) don't really know the in's and out's
> of Windows's internationalization support.  Are you saying that
> supporting UTF-8 filenames and StringAttributes would not suffice for
> international Windows users?
> 

My apologies, I thought this is was only about file names.

For the issue of filenames, UTF8 support will not allow you to open 
Japanese-named files on Windows.

On UNIX what's happening is that you're passing this string, it gets down in C 
to 'fopen' and eventually to the OS and file system which recognizes the string 
as a UTF8-encoded name.

Windows does not recognize UTF strings in API that take 'char *'.  In the case 
of 'fopen', there is an 'fopen' for ascii names, and 'wfopen' for wide-char 
strings (which eventually call the OS's CreateFileA, CreateFileW).   (It's 
possible Visual C++ 2005 Run-time library's implementation of fopen has changed 
and can recognize and convert UTF8 to WCHAR before calling the OS, but previous 
versions do not)

I haven't comb the OpenEXR library closely, but if you use ifstream, there is 
an equivalent wifstream.

Typically what people do is strategically place an #if defined(WIN32) && 
defined(UNICODE), and let the developer build a Unicode version of the library, 
although it can indeed be handled by implementing a custom low-level I/O.  I've 
noticed however that the IStream has a method that returns a "const char *", 
which would produce garbled error messages if you're using it to create error 
message strings.

For saving attributes in a file, utf-8 really makes sense.  Saving wchar_t is 
not something one would do because its definition is not standard, it isn't 
even the same size between between Windows (16 bit) and Linux (32-bit).  It's 
completely fine to use that type for function and method parameters at 
run-time, however, it's standard c++.