winefile: switch to UNICODE mode

[Martin Fuchs]

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?

[Marcelo Duarte]

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

[Martin Fuchs]

Hi Marcelo,

2005/6/20, Marcelo Duarte :
> 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

[Alexandre Julliard]

Martin Fuchs  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.

[Martin Fuchs]

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

[Frank Richter]

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.

[Martin Fuchs]

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

[Alexandre Julliard]

Martin Fuchs  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.

[Martin Fuchs]

22 Jun 2005 10:36:22 +0200, Alexandre Julliard :
> Martin Fuchs  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

[Alexandre Julliard]

Martin Fuchs  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.

[Martin Fuchs]

22 Jun 2005 22:37:34 +0200, Alexandre Julliard :
> Martin Fuchs  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