[Gdal-dev] Windows CE port of GDAL - work started

[Mateusz Łoskot]

> -----Original Message-----
> From: Alain Rist [mailto:ar at navpoch.com] 
> Sent: Friday, September 16, 2005 11:15 AM
> To: 'Mateusz Loskot'; gdal-dev at lists.maptools.org
> Subject: {Definitely Spam?} RE : [Gdal-dev] Windows CE port of GDAL - work started
> 
> 
> Hi Mateusz,
> 
> I am VERY interested.
> 
> How do you intend to deal with the Unicode issues ?
> 

Hi Alain,

Yes, Unicode is a problem (or beneficial).
I talked to Frank about how I should solve Unicode problem.
We decided that GDAL/OGR interface shouldn't be changed to Unicode-like interface,
but Unicode will be wrapped inside the library.
Not very clear? I thought so.
Let's take some example.

CPLGetSymbol function from cplgetsymbol.cpp file.
This function calls LoadLibrary from Win32 API.
LoadLibrary is a typedef of LoadLibraryA or LoadLibraryW, depending on that you
are compiling with UNICODE support or not.
For Windows CE you always compile software with UNICODE support.
So, in our example, LoadLibraryW will be called in place of LoadLibrary call.
W - means wide-char version, A - means ANSI character set.
How I handle such CPLGetSymbol function?
Simply, I wrap LoadLibrary call in CPLGetSymbol with #ifdef...#endif and for Windows CE version and
I do ANSI->Unicode conversion (string with library path in our example) then I call LoadLibrary -> LoadLibraryW.

Summary
All ANSI char-based API of GDAL/OGR won't be changed (const char* won't be changed to const wchar_t*).
So, client application will use chars not wide-chars and (what is certainly a problem) has to convert
Unicode strings to char-strings (certainly, not all strings) while passing strings to GDAL/OGR API.

Simple, I follow the same approach as in Shapelib and sqlite for Windows CE.
It seems it works well on Windows CE and there are not many confusions working with such ports.


It is simple and not very genius, so if anyone has better solution, please give me a note.

-- 
Mateusz Łoskot
mateusz at loskot dot net