_TCHAR

_TCHAR

[Lars Poeschel]

Hello!

In ecos/host/tools/Utils/common/wcharunix.h
_TCHAR is typdef'd as char. Shouldn't it be wchar_t for unicode builds ?
Is wcharunix.h only included in unix-builds or does Windows use it also 
?

Thanks,

Lars

Re: _TCHAR

[Andrew Lunn]

On Wed, May 10, 2006 at 07:13:33PM +0200, Lars Poeschel wrote:
> Hello!
> 
> In ecos/host/tools/Utils/common/wcharunix.h
> _TCHAR is typdef'd as char. Shouldn't it be wchar_t for unicode builds ?
> Is wcharunix.h only included in unix-builds or does Windows use it also 

I know very little about unicode, so please ignore what i say....

I think wcharunix.h needs remove altogether. The wxWidgets wxchar.h
and the system <wchar.h> should be used.

    Andrew

Re: _TCHAR

[Lars Poeschel]

Am 10.05.2006 um 20:07 schrieb Andrew Lunn:

> On Wed, May 10, 2006 at 07:13:33PM +0200, Lars Poeschel wrote:
>> Hello!
>>
>> In ecos/host/tools/Utils/common/wcharunix.h
>> _TCHAR is typdef'd as char. Shouldn't it be wchar_t for unicode 
>> builds ?
>> Is wcharunix.h only included in unix-builds or does Windows use it 
>> also
>
> I know very little about unicode, so please ignore what i say....

I do not do that, because you have an interesting idea! ;-)

> I think wcharunix.h needs remove altogether. The wxWidgets wxchar.h
> and the system <wchar.h> should be used.

I think, this is not possible very easily because many Files outside 
the wx configtool depend on functions where aliases are defined in 
wcharunix.h such as _tprintf are #define'd here and allow us to use 
wprintf in unicode builds and printf for ansi builds.
I think that should stay here (maybe change the name of the file to 
someting more descriptable in that case). But to remove the TCHAR 
defines and typedefs here and use system/wxWidgets' instead is not the 
worst idea! From the programmers point of view this can make things 
much easier, since unicode support of wxWidgets seems very good to me 
and I could save much of the wchart_t <-> char conversion for library 
functions where GNU does not provide wide character versions.
But the other side is, that we would possibly have depencies on 
wxWidgets in non gui-programs or libraries such as the command line 
config tool.What do you think ? Should I take the step and rely on 
wxWidgets ?

Lars

Re: _TCHAR

[Andrew Lunn]

On Wed, May 10, 2006 at 08:58:37PM +0200, Lars Poeschel wrote:
> 
> Am 10.05.2006 um 20:07 schrieb Andrew Lunn:
> 
> >On Wed, May 10, 2006 at 07:13:33PM +0200, Lars Poeschel wrote:
> >>Hello!
> >>
> >>In ecos/host/tools/Utils/common/wcharunix.h
> >>_TCHAR is typdef'd as char. Shouldn't it be wchar_t for unicode 
> >>builds ?
> >>Is wcharunix.h only included in unix-builds or does Windows use it 
> >>also
> >
> >I know very little about unicode, so please ignore what i say....
> 
> I do not do that, because you have an interesting idea! ;-)
> 
> >I think wcharunix.h needs remove altogether. The wxWidgets wxchar.h
> >and the system <wchar.h> should be used.
> 
> I think, this is not possible very easily because many Files outside 
> the wx configtool depend on functions where aliases are defined in 
> wcharunix.h such as _tprintf are #define'd here and allow us to use 
> wprintf in unicode builds and printf for ansi builds.

ecosconfig should not depend on wx. Part of the problem that nobody
builds configtool from sources, is that it needs wx and it is hard to
build. ecosconfig on the other hand is easy to build and it should
stay that way. configtool is only nice to have. ecosconfig is
necassary and has to remain easy to build.

Maybe you need a mixture of wcharunix.h and other header files. You
should be able to rely on <wchar.h> since it is part of libc. So try
to get as much as possible from there. Then just add what is missing
in wcharunix.h. 

I suppose another approach is find out what the POSIX way is of doing
this. I guess the current code is following the M$ way of doing it,
which might not be too portable to *nix systems. However the POSIX way
of doing it might be more portable and work on M$ systems.

      Andrew