Re: [Cppunit-devel] Patch for UNICODE build

[CppUnit d. m. l. <cpp...@li...>]

 > I am not at all familiar with windows API.  Your patch changes a
 > couple of calls from "foo()" to "fooA()"; how do the "A" functions
 > different from their non-A version?  Does this now *require*
 > compilation in unicode?  What does that mean, exactly?

It is quite simple (?)
In the Win32 API, every function taking a string in argument (or a=20
structure containing strings) exists in two versions :
- the A version : ANSI, takes "strings" of char
- the W version : UNICODE, takes L"strings" of WCHAR

The "normal" untagged version is in fact a define :
If UNICODE is defined, the define is bound to the W version.
If not, the define is bound to the A version.

Ugly example taken from winbase.h :
WINBASEAPI
HMODULE
WINAPI
LoadLibraryA(
     LPCSTR lpLibFileName
     );
WINBASEAPI
HMODULE
WINAPI
LoadLibraryW(
     LPCWSTR lpLibFileName
     );
#ifdef UNICODE
#define LoadLibrary  LoadLibraryW
#else
#define LoadLibrary  LoadLibraryA
#endif // !UNICODE

Furthermore, there is something like this in winnt.h :
typedef wchar_t WCHAR;    // wc,   16-bit UNICODE character
#ifdef  UNICODE                     // r_winnt
typedef WCHAR TCHAR, *PTCHAR;
#else   /* UNICODE */               // r_winnt
typedef char TCHAR, *PTCHAR;
#endif /* UNICODE */                // r_winnt

An UNICODE program :
- store strings into WCHAR[] instead of char[]
- calls the UNICODE "W" API instead of the classic ANSI "A" API.
Because each character is coded on 16 bits, it can store any character=20
in the world without having to deal with codepages. Windows NT works=20
internally in UNICODE, so UNICODE programs are the best choice for=20
Windows NT. But they don't work on Win9x.

Thanks to the UNICODE define, a program written carefully with TCHAR=20
instead of char (and a LOT of other macros) can be compiled either in=20
ANSI or UNICODE version.

CppUnit is not UNICODE-aware, because it stores its strings in=20
std::string, which is internally a char[]. So it should always call the=20
ANSI version of the Win32 API, regardless to the UNICODE define.

My patch just replaces the untagged Win32 functions with the specific A=20
versions.
When UNICODE is not defined, there is absolutely no difference with or=20
without my patch.

But when UNICODE is defined, the file Win32DynamicLibraryManager.cpp=20
does not compile becauses it passes std::string (which are always ANSI=20
as far as I know) to the UNICODE "W" API. It fails with type mismatch.

The simpliest solution to make this source compile when UNICODE is=20
defined is to call explicitly the ANSI API.
Another solution may have been to convert the strings before calling the=20
generic API.
And of course, the best solution would be to make CppUnit fully=20
unicode-aware (not using std::string but... I don't know what).

In conclusion : this tiny patch avoids compilation errors when compiling=20
the CppUnit library when UNICODE is defined. But of course it is not=20
required to define it !
You may ask : "Why the hell do you compile CppUnit with UNICODE defined=20
?" Well, it's just to have exactly the same compilation options for all=20
the static libraries composing my projects - including CppUnit itself.

Vincent Rivi=E8re
vri...@us...