About UNICODE<->ASCII support.

[carlo.bramix]

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.

[Colin Finck]

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

[Ged]

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(a)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: [phone]
f: [phone]

Registered in England No 4760795

http://www.amteus.com

[Colin Finck]

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

[Ged Murphy]

On Nov 5, 2007 5:53 PM, Colin Finck <mail(a)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)

[KJK::Hyperion]

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)