Hello everyone, I just would like talk about a recent fix applied to one of the components of ReactOS. It is not my intention to make problems in any way with this topic, or pretending a change of the direction taken by the project (peace!). In that recent change, the hybrid support for both ASCII and UNICODE support into task manager has been dropped. I would like that you try to review your opinion on such changes. Me too, I want final builds of executables in unicode format. I think to know almost all advantages of international support. However, I also believe that you should not see the ASCII support as something to throw out of the window, but as a chance, because not all applications in the world are compiled as unicode, so having something to test the ASCII implementation included into ROS is not a so bad idea. As I said, it is a chance for testing. Some of the work here seems derived from wine, but probably (or better: surely) people behind wine had to face to the problem called "debugging" before they got something stable. A closed-source application may not work, but at least there is a chance (perhaps minimal or even less) to replicate a bug into one of the applications available to us. Technically, it isn't a problem for me to make things working on win9x, since I just need to link to UNICOWS.DLL and the problem is almost solved. I just don't like very much that position. And I also understand that my opinion isn't important at all in front of your decisions or the ReactOS standard.
Sincerely,
Carlo Bramini.
Hi Carlo,
carlo.bramix wrote: In that recent change, the hybrid support for both ASCII and UNICODE support into task manager has been dropped.
Such a hybrid support already did not exist *for Task-Manager* before. If you tried to just remove the UNICODE definitions from the .rbuild file, it still did not build.
The Task-Manager makes use of some functions defined in the NDK headers and these native functions are only available for Unicode. One of the NDK headers also defines UNICODE, so you would need to override this explicitly in the code and not just in the .rbuild file. Furthermore you would need WideCharToMultiByte to convert the Unicode values to ANSI, which could lead to data corruption if the Unicode characters are not available for the current ANSI codepage. This is why we decided to drop the Unicode "support" for Task-Manager completely. To make this obvious, I also changed the code, so it doesn't use TCHAR's and "tchar.h" anymore.
Technically, it isn't a problem for me to make things working on win9x, since I just need to link to UNICOWS.DLL and the problem is almost solved.
But this would not work for Task-Manager as the used functions defined in the NDK are not available under Win9x.
As said, this decision was just done for Task-Manager. In general, I also try to make applications compilable with both Unicode turned on and off.
Regards,
Colin
carlo.bramix
In that recent change, the hybrid support for both ASCII and UNICODE support into task manager has been dropped. I would like that you try to review your opinion on such changes.
This is the wrong way to be working. We should be dropping support for ASCII where ever possible now. There's rarely an excuse for TCHAR now, ASCII is dead this is a unicode operating system. It's time to move on.
I consider ASCII to be quite rude, think about people with non ASCII languages, they shouldn't have to live by American standards. The sooner it's eradicated, the better it will be for everyone.
However, I also believe that you should not see the ASCII support as something to throw out of the window, but as a chance, because not all applications in the world are compiled as unicode, so having something to test the ASCII implementation included into ROS is not a so bad idea.
ASCII apis simply convert strings and call the unicode apis. I hardly think it's worth keeping all our base apps ASCII complaint just as a possible test case for these APIs If we want test cases, then it's better to write them
Ged.
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
Amteus Secure Communications Ltd 57 Cardigan Lane, Leeds, LS4 2LE t: +44 (0) 870 8368770 f: +44 (0) 870 8368701
Registered in England No 4760795
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? When I joined the project, I was told that I should use TCHAR for all user-mode stuff (except libraries), so people can easily compile them either as ASCII or as Unicode versions.
I think that simply dropping support for ASCII isn't the right way to go. The whole thing mainly boils down on a decision between WCHAR and TCHAR, so why not use TCHAR here? This shouldn't be a big deal.
Regards,
Colin
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)
Colin Finck ha scritto:
I think that simply dropping support for ASCII isn't the right way to go. The whole thing mainly boils down on a decision between WCHAR and TCHAR, so why not use TCHAR here? This shouldn't be a big deal.
Because you (yes, you) are not going to keep the promise you're making by using TCHAR. It might be sooner, it might be later, one day you'll have to interface with an Unicode-only API, and you can bet your ass you will not have any conditional code or helper routine to convert from LPTSTR to LPWSTR. Unless you are using ATL (you aren't)
-
carlo.bramix -
Colin Finck -
Ged -
Ged Murphy -
KJK::Hyperion