winefile: switch to UNICODE mode
Changelog: switch winefile to UNICODE mode Why did I declare a new macro $(PREINCL) and insert it into Make.rule.in ? To allow inserting the include directory <include/msvcrt> before <include>. Another way would be to change the following line in Make.rule.in and move $(EXTRAINCL) before -I$(TOPSRCDIR)/include: INCLUDES = -I$(SRCDIR) -I. $(EXTRAINCL) -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include Why did I remove the following from include/tchar.h? #if defined(_UNICODE) || defined(_MBCS) #error You must use msvcrt when building in Unicode/MBCS mode #endif Because it's just crazy - a few lines later _UNICODE and _MBCS are used to build the A/W mapping macros: /***************************************************************************** * tchar mappings */ #ifndef _UNICODE # ifndef _MBCS # include <string.h> # define WINE_tchar_routine(std,mbcs,unicode) std # else # include <mbstring.h> # define WINE_tchar_routine(std,mbcs,unicode) mbcs # endif #else /* _UNICODE */ # include <wchar.h> # define WINE_tchar_routine(std,mbcs,unicode) unicode #endif If _UNICODE and _MBCS would not be allowed to be used in <tchar.h> at all, what would be the sense of the whole file?
Martin Fuchs escreveu:
Changelog: switch winefile to UNICODE mode
I don´t understand something or winefile can use Michael Jung´s unixfs namespace extension?
+ +/* functions in unixcalls.c */ + +extern void call_getcwd(char* buffer, size_t len); +extern void* call_opendir(const char* path); +extern int call_readdir(void* pdir, char* name, unsigned* pinode); +extern void call_closedir(void* pdir); + +extern int call_stat( + const char* path, int* pis_dir, + unsigned long* psize_low, unsigned long* psize_high, + time_t* patime, time_t* pmtime, + unsigned long* plinks +); + #endif
Hi Marcelo, 2005/6/20, Marcelo Duarte <marcelotduarte(a)gmail.com>:
I don´t understand something or winefile can use Michael Jung´s unixfs namespace extension?
The difference is: The unixfs namespace extension is implemented in shell namespace. This is a quite huge overhead compared to directly accessing unix file system functions because of all the PIDL conversions. So you will notice a big difference in performance using the "root filesystem" in winefile compared to using the "shell namespace" (another option already existing in winefile). Regards, Martin
Martin Fuchs <martin-fuchs(a)gmx.net> writes:
Why did I declare a new macro $(PREINCL) and insert it into Make.rule.in ? To allow inserting the include directory <include/msvcrt> before <include>.
But why do you need that?
-IMPORTS = shell32 comdlg32 comctl32 ole32 mpr version user32 gdi32 advapi32 kernel32 +PREINCL = -I$(TOPSRCDIR)/include/msvcrt +IMPORTS = msvcrt shell32 comdlg32 comctl32 ole32 mpr version user32 gdi32 advapi32 kernel32 EXTRALIBS = -luuid
C_SRCS = \ license.c \ splitpath.c \ + unixcalls.c \ winefile.c
RC_SRCS = rsrc.rc @@ -22,5 +24,11 @@ winefile.ico
@MAKE_PROG_RULES@ + +UNIX_INCLUDES = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include +UNIX_CFLAGS = $(UNIX_INCLUDES) $(DEFS) $(DLLFLAGS) $(EXTRACFLAGS) $(CPPFLAGS) $(CFLAGS) + +unixcalls.o: unixcalls.c + $(CC) -c $(UNIX_CFLAGS) -o $@ $<
This stuff is getting uglier all the time. Please consider converting to Unicode properly and getting rid of all the TCHAR crap. I know the goal is to show how to use it, but at this point all it does is demonstrate why using TCHAR is a really bad idea. The way this is going pretty soon there will be more #ifdefs in winefile than in all the rest of the Wine codebase. -- Alexandre Julliard julliard(a)winehq.org
Hi,
This stuff is getting uglier all the time. Please consider converting to Unicode properly and getting rid of all the TCHAR crap. I know the goal is to show how to use it, but at this point all it does is demonstrate why using TCHAR is a really bad idea. The way this is going pretty soon there will be more #ifdefs in winefile than in all the rest of the Wine codebase.
The pure existence of <include/tchar.h> in the Wine code base shows me, Wine is aimed to support TCHARs. So why don't you want to properly activate its functionality and take Winefile as an example how to use it? Otherwise if you are consequent, you should deprecate it officially for Winelib applications, and remove it completely from the header files. By the way: There currently only 12 #if(n)def UNICODEs in Winefile, and I don't expect this number to increase very much at any time. I know, I won't be able to convince you. Any one out there to support my point of view? ;-) Regards, Martin
On 21.06.2005 23:12, Martin Fuchs wrote:
The pure existence of <include/tchar.h> in the Wine code base shows me, Wine is aimed to support TCHARs.
It may also just show that Wine wants to be compatible with existing sources that use <tchar.h>, it doesn't necessarily say anything about the internal use of it or whether new applications should employ it. AFAIK TCHARs were devised quite a while ago to allow compilation of a single codebase for both ANSI (ie Win9x) and Unicode (ie WinNT) APIs. If you know you'll run on a platform that thoroughly supports Unicode, there's just no point in carrying around the TCHAR baggage. Make life for you and everyone else easier and give an example how to write a proper Unicode (and only Unicode) application. -f.r.
On 21.06.2005 23:44:21 Frank Richter wrote:
On 21.06.2005 23:12, Martin Fuchs wrote:
The pure existence of <include/tchar.h> in the Wine code base shows me, Wine is aimed to support TCHARs.
It may also just show that Wine wants to be compatible with existing sources that use <tchar.h>, it doesn't necessarily say anything about the internal use of it or whether new applications should employ it.
Sure, <tchar.h> is not designed to be used "internally" in Wine. But the point is, I would like to maintain Winefile such, that it isn't constraint to being used in Wine only. For example it is currently also present in ReactOS. The idea is to allow compiling it in ANSI mode for that cases, that don't provide or need Unicode. Win 9x systems don't provide Unicode functions. Embedded systems don't have available much memory resources, so they try to spare as much memory as possible. Currently there isn't yet a ReactOS port for such environments. But why not prepare for such a situation yet now? Regards, Martin
Martin Fuchs <fuchs.martin(a)gmail.com> writes:
Sure, <tchar.h> is not designed to be used "internally" in Wine. But the point is, I would like to maintain Winefile such, that it isn't constraint to being used in Wine only. For example it is currently also present in ReactOS. The idea is to allow compiling it in ANSI mode for that cases, that don't provide or need Unicode.
There is no such case anymore, Win9x has unicows so you can use Unicode there. And ReactOS obviously supports Unicode too.
Win 9x systems don't provide Unicode functions. Embedded systems don't have available much memory resources, so they try to spare as much memory as possible. Currently there isn't yet a ReactOS port for such environments. But why not prepare for such a situation yet now?
Surely you are joking. There is no support in Wine for disabling Unicode support, and there never will be (nor in ReactOS since it's using our dlls). So all you can hope to gain is a couple of bytes of storage for the strings internal to winefile, which is completely negligible. -- Alexandre Julliard julliard(a)winehq.org
22 Jun 2005 10:36:22 +0200, Alexandre Julliard <julliard(a)winehq.org>:
Martin Fuchs <fuchs.martin(a)gmail.com> writes:
Sure, <tchar.h> is not designed to be used "internally" in Wine. But the point is, I would like to maintain Winefile such, that it isn't constraint to being used in Wine only. For example it is currently also present in ReactOS. The idea is to allow compiling it in ANSI mode for that cases, that don't provide or need Unicode.
There is no such case anymore, Win9x has unicows so you can use Unicode there.
Let me change the question: Why should one use Unicode on those systems at all? They don't support Unicode file systems - so there are no 16 bit file names to display. There are two small problems with unicows (not mentioning it's just a hack in my mind): First MinGW doesn't support unicows. One has to use VC++ instead. Second it doesn't work with winefile. I just tried and linked against unicows.lib. Even after removing the call to SHBindToParent() it doesn't run on WIN98. Don't ask me why - it just doesn't show any window or error message. I also don't feel the urge of hinting for the cause and building some work around. Oh well - what's all this discussion about? 1.) I want to sync the last few differences of winefile's source code between ReactOS and Wine. ReactOS is already using the UNICODE version. (by using TCHAR strings and compiling with -DUNICODE) Wine's winefile is currently compiled in ANSI mode. Just taking the ReactOS version for Wine doesn't work because of the special "Unixfs" feature. 2.) I would like to retain the opportunity to compile Winefile in ANSI mode. For whatever reason. ;-) 3.) Wine's TCHAR support is not complete. You didn't answer on this fact yet. This makes the proper implementation of TCHAR usage combined with Unix calls kind of ugly. So you don't like it. What are the ways out of this dilemma? a.) Enable TCHAR support for Winefile in Wine and commit my patch b.) move completely to UNICODE in both source trees c.) move to UNICODE, but open a branch/set a tag for an ANSI or TCHAR version d.) just don't change anything and let Wine use an ANSI winefile version like all the years ago I (and one more till now) vote for a.) You, and some more vote for b.) d.) doesn't solve the problem of diverging source codes. So if there are not more votes for a.) I will consider c.). (not quite sure if to open the branch in ROS SVN or only privately for me) Regards, Martin
Martin Fuchs <fuchs.martin(a)gmail.com> writes:
Let me change the question: Why should one use Unicode on those systems at all? They don't support Unicode file systems - so there are no 16 bit file names to display.
No, but using Unicode doesn't hurt, and is easier than going through the effort of not using it.
3.) Wine's TCHAR support is not complete. You didn't answer on this fact yet. This makes the proper implementation of TCHAR usage combined with Unix calls kind of ugly. So you don't like it.
You cannot combine TCHAR with Unix, because Unix doesn't use the same size of wide character. There is no way this can be made to work with the tchar.h macros. -- Alexandre Julliard julliard(a)winehq.org
22 Jun 2005 22:37:34 +0200, Alexandre Julliard <julliard(a)winehq.org>:
Martin Fuchs <fuchs.martin(a)gmail.com> writes:
Let me change the question: Why should one use Unicode on those systems at all? They don't support Unicode file systems - so there are no 16 bit file names to display.
No, but using Unicode doesn't hurt, and is easier than going through the effort of not using it.
It hurts my sense of avoiding waste to fill each second byte with zero, just to let another layer (unicows) remove it again. Native solutions are always better. You don't accept that. OK. Likewise hurts the current representation of wide character string constants instead of using -fshort-wchar my sense of prettiness. You care more about compatibility to some outdated compilers. OK. But that's another topic.
3.) Wine's TCHAR support is not complete. You didn't answer on this fact yet. This makes the proper implementation of TCHAR usage combined with Unix calls kind of ugly. So you don't like it.
You cannot combine TCHAR with Unix, because Unix doesn't use the same size of wide character. There is no way this can be made to work with the tchar.h macros.
This is only one side of the medal. It makes impossible using tchar.h with -DUNICODE together with unix header files in one compilation module. But my patch shows, it would be possible to use -DUNICODE together with <tchar.h> by just a few changes. Currently you only get those missleading error message "You must use msvcrt when building in Unicode/MBCS mode". Regards, Martin
participants (5)
-
Alexandre Julliard -
Frank Richter -
Marcelo Duarte -
Martin Fuchs -
Martin Fuchs