winelib + unicode
wouldn't it be nice to have winemaker-generated sources automatically add -fshort-wchar to the C compiler options? To make this robust, one could write a configure test for it. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: winelib + unicode
On December 11, 2002 08:13 am, Martin Wilck wrote: wouldn't it be nice to have winemaker-generated sources automatically add -fshort-wchar to the C compiler options? I personally don't understand why we even bother with other options. The -fshort-wchar is the only correct fix to the problem, and just by enumerating the other hacks we just confuse the issue. Who is crazy enough to use the other hacks where there is such a simple (and correct) fix available? This option is probably supported nowadays by most gcc installations, and for the 1 in 1000 that doesn't want to use it (for whatever reason), they will bring it up on wine-devel and they'll get an answer. No point in cluttering the documentation (Winelib User's Guide), the scripts (winemaker), etc. with them. -- Dimi.
Re: winelib + unicode
Am Mit, 2002-12-11 um 16.17 schrieb Dimitrie O. Paun: The -fshort-wchar is the only correct fix to the problem, and just by enumerating the other hacks we just confuse the issue. Agreed - at least I see no need for automating them. Who is crazy enough to use the other hacks where there is such a simple (and correct) fix available? This option is probably supported nowadays by most gcc installations, and for the 1 in 1000 that doesn't want to use it (for whatever reason), they will bring it up on wine-devel and they'll get an answer. No point in cluttering the documentation (Winelib User's Guide), the scripts (winemaker), etc. with them. well the configure script should probably check if -fshort-wchar is supported, add the option to CFLAGS if yes, and issue a warning if no. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: winelib + unicode
On December 11, 2002 10:52 am, Martin Wilck wrote: well the configure script should probably check if -fshort-wchar is supported, add the option to CFLAGS if yes, and issue a warning if no. But the problem is that winemaker will run on different systems that configure runs on... It will get it mostly right, but now always. However, my comment was referring to this bit: http://www.winehq.org/Docs/winelib-user/unicode.shtml It makes things look complicated. It should be: Use a gcc that support -fshort-wchar (2.9.7 or later) Instead, we present 3 options as if they are *equally* likely/desirable, and then we let the poor developer not familiar with the problem to agonize over which option to use. In reality, 1. is likely used in 99.999% of case, the others are clever hacks that are maybe interesting for historical reasons nowadays. I think we should try to make the documentation concise, not long. Most people think that the quality of documentation is measured in pages. Often times, is inversely proportional. Let's try to document a preferred way of doing things (maybe present some options when they are equally likely). That being said, I want to stress that this is a minor nit, and that I actually like our documentation (incomplete as it is). I just picked it up as an excuse for my daily rant... :) -- Dimi.
Re: winelib + unicode
Am Mit, 2002-12-11 um 16.49 schrieb Dimitrie O. Paun: On December 11, 2002 10:52 am, Martin Wilck wrote: well the configure script should probably check if -fshort-wchar is supported, add the option to CFLAGS if yes, and issue a warning if no. But the problem is that winemaker will run on different systems that configure runs on... It will get it mostly right, but now always. I can't follow you. Winemaker generates a configure.ac file. You need to run autoconf and configure anyway to build your code. We just need to make sure that Winemaker puts a test for -fshort-wchar into configure.ac. What am I missing? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: winelib + unicode
On December 11, 2002 12:05 pm, Martin Wilck wrote: I can't follow you. Winemaker generates a configure.ac file. You need to run autoconf and configure anyway to build your code. We just need to make sure that Winemaker puts a test for -fshort-wchar into configure.ac. What am I missing? Nothing. I forgot that winemaker generates a configure.ac file as well. :) So yeah, a test in there would be good, if it fails we should report an error. If someone really needs to use the other hacks, they can just edit the configure.ac to take the test out. -- Dimi.
Re: Winelib + Unicode
On Jan 17, 2001, Jon Griffiths [EMAIL PROTECTED] wrote: 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... If you do get some docs written, by all means submit it to one of the Wine guides (the Winelib User Guide?). If you don't feel like writing it in DocBook, you can just send me the plain ASCII text, and I'd be happy to convert it and find a good place for it. John -- [EMAIL PROTECTED]http://www.gnome.org [EMAIL PROTECTED] http://www.worldforge.org [EMAIL PROTECTED] http://openbooks.sourceforge.net http://advogato.org/person/jsheets Writing Gnome Applications http://www.aw.com/cseng/titles/0-201-65791-0/
Re: Winelib + Unicode
If you do get some docs written, by all means submit it to one of the Wine guides (the Winelib User Guide?). If you don't feel like writing it in DocBook, you can just send me the plain ASCII text, and I'd be happy to convert it and find a good place for it. big grin I was hoping someone would say that... I can't stand working in markup. I'll fire something over to you once the patches required to make it work for me have been sent comitted. On a related note, I think tools/specmaker/README really belongs in the Winelib user guide under "dealing with binary only DLL's" as well, since that pretty much what it covers. Thanks regards, Jon -- "Once you realise you're not _meant_ to fit in, it all makes sense..." [EMAIL PROTECTED] , [EMAIL PROTECTED]
Re: Winelib + Unicode
Hi, Use gcc 2.97 with -fshort-wchar. Well, this was for VWCL, and I wanted to make the price of entry as low as possible for the existing win programmers, so I've gone for another solution; since its a C++ framework its sufficient to use #define VTEXTW(str) wine_unicode_text(L##str) and give -fwritable-strings, which is working. I'll put CVS gcc on the ever increasing list of things to look at in the future :-) Thanks, Jon -- "Once you realise you're not _meant_ to fit in, it all makes sense..." [EMAIL PROTECTED] , [EMAIL PROTECTED]
Re: Winelib + Unicode
Jon Griffiths wrote:
Hi,
Use gcc 2.97 with -fshort-wchar.
Well, this was for VWCL, and I wanted to make the price of entry as low as
possible for the existing win programmers, so I've gone for another solution;
since its a C++ framework its sufficient to use
#define VTEXTW(str) wine_unicode_text(L##str)
and give -fwritable-strings, which is working. I'll put CVS gcc on the ever
increasing list of things to look at in the future :-)
Well, if you're willing to modify your code then you should probably
use WINE_UNICODE_TEXT. That's because:
* it supports both chars and strings, i.e. you can write:
WINE_UNICODE_TEXT('c') as well as WINE_UNICODE_TEXT("string")
I agree that it's a bit ugly but I had to do it because that's what
they do with OLESTR in the MFC! In C I believe you will have warnings
(but at least it will compile and do the right thing). You might want to
have two macros instead.
* it will do the right thing when you switch to g++ 2.97, i.e. it will
become L##x
Of course the name is a bit long (and it's WINE specific) so you
could do:
#define VTEXTW(x) WINE_UNICODE_TEXT(x)
--
Franois Gouget
[EMAIL PROTECTED]
Re: Winelib + Unicode
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]
Re: Winelib + Unicode
Jon Griffiths wrote: 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) [...] 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. That's right, it does not address the crt issues at all. 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. 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. -- Franois Gouget [EMAIL PROTECTED]
Re: Winelib + Unicode
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. 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). Cheers, Jon -- "Once you realise you're not _meant_ to fit in, it all makes sense..." [EMAIL PROTECTED] , [EMAIL PROTECTED]
Re: Winelib + Unicode
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
Re: Winelib + Unicode
On Tue, 16 Jan 2001, Jon Griffiths wrote: [...] Under windows, __TEXT gives you a string in ascii or u/c depending on whether UNICODE is defined. But you can still always get a u/c string by using L"foo". With winelib this gives you a glibc u/c string :-( Use gcc 2.97 with -fshort-wchar. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner
