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 : ros-dev-bounces@reactos.org
To : "ReactOS Development List" ros-dev@reactos.org 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 mail@colinfinck.de 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 Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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
On Nov 7, 2007 11:03 AM, Colin Finck mail@colinfinck.de 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.
On Nov 7, 2007 9:03 AM, Colin Finck mail@colinfinck.de 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