Hi,
> Of course the name is a bit long (and it's WINE specific) so you
> could do:
>
> #define VTEXTW(x) WINE_UNICODE_TEXT(x)
In this case the macro is only used in c++, so I used what WINE_UNICODE_TEXT
expands to in this context; this works for single chars and strings. I think
to be realistic by the time msvcrt is ready (headers and all) for really
heavy use (like switching the default to native), gcc 3.0 will be out and
developers will once again have a choice between ms and libc crts. For now if
you use Unicode and call win32 wc functions with u/c strings, your only
choice is to either suffer the in development msvcrt or use a cvs gcc :-(
Actually, having said that, have you tested -fshort-wchar? does it require
libc to be rebuilt? or just to build with a different set of headers (i.e.
lib funcs still cannot be used)? My assumption is that it just changes the
behaviour of L'foo', and doesn't address the crt issues at all.
I'm working on wide char functions in msvcrt now since thats whats preventing
VWCL from working, and forms the largest slice of unimplemented
functionality. I have VCWL (using msvcrt) compiling with some hacked up
headers but need to implement some more wc funcs in order to get the first
test apps running. After this I'll clean up the headers for submission and
document the crt choices for the Winelib user guide. Following that theres
the issue of adding the ms crt startup calls to winebuild, but I didn't get
any feedback on that, so I'm letting it sit for a while ;-)
Thanks for the feedback though. If I get time I might scribble up some docs
on using unicode. Its taking a little getting used to, so it might be useful
for others working with Winelib in the future...
Cheers,
Jon
--
"Once you realise you're not _meant_ to fit in, it all makes sense..."
[EMAIL PROTECTED] , [EMAIL PROTECTED]
