Re: [ros-dev] About UNICODE<->ASCII support.

[carlo.bramix]

Hello,
honestly, your enthusiasm seems a bit to exagerated to me!
In the specific case, it looks like that all TCHARs in Taskmgr have been converted to WCHAR because the programme receives from the API some informations that are UNICODE only.
I can understand and I agree to that, afterall it can be made working with unicows layer, if someone wants (and infact, I did it).
Athough you should also admit that two WideCharToMultiByte() calls are not exactly something we can call "drammatic" code, which is automatically excluded by the presence of the magic UNICODE macro.
I also agree with the fact that there could be the source code which interacts with UNICODE-only variables and the direct usage of WCHAR instead of TCHAR is very helpful and clean.
But how many functions have this behavior (WCHAR-only)?
It is not too difficult to count them and in my opinion this does not justify a refresh of sources for making TCHAR>WCHAR, or MessageBox>MessageBoxW...
Last but not last... human beings can do errors, their changes may always introduce new errors, so more time for testing, etc...
If I can do a suggestion, I would avoid unnecesary changes for this reason too.
Afterall the binary code of the executable won't change by a single bit when TCHARs are converted to WCHARs at compile time, if there are not drawbacks like tons of conversions which will make the source code unreadable (it's also important that people understand the code for contribuiting).
But if there are just TCHARs/_tcscpy/... I don't understand the reason.

Sincerely,

Carlo Bramini.

---------- Initial Header -----------
> From      : [e-mail]

To          : "ReactOS Development List" [e-mail]
Cc          : 
Date      : Mon, 5 Nov 2007 23:55:35 +0000
Subject : Re: [ros-dev] About UNICODE<->ASCII support.
> On Nov 5, 2007 5:53 PM, Colin Finck [e-mail] wrote:
> > Hi Ged,
> > > Ged wrote:
> > > This is the wrong way to be working. We should be dropping
> > > support for ASCII where ever possible now.
> >
> > Is this really the official course now?
>
> This has pretty much always been the course.
> There is absolutely no reason to use TCHAR, it was relevant 10 years
> ago, but not any more.
>
> (btw, in case anyone thinks I'm contradicting myself with mstsc, TCHAR
> is only being used as it's currently a port of an ASCII app)
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Colin Finck]

carlo.bramix wrote:
> I can understand and I agree to that, afterall it can be made 
> working with unicows layer, if someone wants (and infact, I did it).

For what reason shall someone do that?
Unicows only makes sense on Win9x and the Task-Manager doesn't work under
these operating systems as it uses NT-only API's.
> Athough you should also admit that two WideCharToMultiByte()
> calls are not exactly something we can call "drammatic" code

As I also said, WideCharToMultiByte() can cause data corruption if a Unicode
character isn't supported by the currently selected ANSI codepage.
MultiByteToWideChar() is no problem, but the other direction can be
problematic.

After all, we're coding for Windows Server 2003-compatibility here.
We don't have to care about compatibility with Win9x (ANSI-only) or previous
NT versions.

Regards,

Colin

[Steven Edwards]

On Nov 7, 2007 11:03 AM, Colin Finck [e-mail] wrote:
> For what reason shall someone do that?
> Unicows only makes sense on Win9x and the Task-Manager doesn't work under
> these operating systems as it uses NT-only API's.

If you have some stupid application that actually needs Unicows, its
already implemented in Wine.
Feel free to import it.
-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[ShadowFlare]

On Nov 7, 2007 9:03 AM, Colin Finck [e-mail] wrote:

As I also said, WideCharToMultiByte() can cause data corruption if a Unicode
> character isn't supported by the currently selected ANSI codepage.
> MultiByteToWideChar() is no problem, but the other direction can be
> problematic.

That is not 100% true.  It is called WideCharToMultiByte and not
WideCharToAnsi for a reason.  It is possible to convert from unicode to UTF8
instead of converting to ANSI, and that will preserve the characters.
Though it may need to be converted back to unicode to display it on Win9x,
for example.

-ShadowFlare