On Thu, 18 Jan 2001, Jon Griffiths wrote:
> > Actually it helps a little in that you can use the standard C library
> > headers (e.g. to get wcslen) and then link with crtdll or msvcrt.
>
> This is what I was wondering; given that they expect wchar_t* and Winelib
> uses WCHAR* I assumed the headers would be useless.
Not so. Because when you us -fshort-wchar you are supposed to also
define WINE_UNICODE_NATIVE and then the definition of WCHAR is:
#ifdef WINE_UNICODE_NATIVE
typedef wchar_t WCHAR, *PWCHAR;
#else
...
Thus the definitions of the Unicode functions in the standard C
headers are just fine (but their implementation of course is not).
> > But the libc C still expect 4byte Unicode chars and I don't expect
> > this to change anytime soon. It would require two implementations of
> > each Unicode function which means two versions of the library.
>
> I think this sounds the end of the idea of the 3 crt scenarios
> (ms/libc/mixed) that were discussed before, for all but the most trivial
> apps. What is left is ms and mixed, where mixed still uses modified headers
> but uses the ignore directive in the apps .spec file to link to the libc
> implementation where desired (and where not already specified in
> msvcrt.spec).
I think that there are many Windows applications that don't really
care about Unicode. These should not have too much trouble with the
native C headers. Concerning Unicode I'm not sure that the mixed headers
should override the definition provided by the native headers. I don't
know.
But for larger programs (or the MFC), the way to go really is to
provide 'msvcrt' headers. Mixing native headers (or mixed headers for
that matter) and crtdll/msvcrt tends to create problems (same thing for
socket.h and winsock.dll).
--
Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/
RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt
IP over Avian Carriers with Quality of Service
