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

[carlo.bramix]

Hello,

>   > 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. 
That's right, it can cause corruption.
But, for an ascii-based OS, it's a compromise for getting the application working
because that application, if compiled in that configuration, will work only on Win9x/ME.
If someone wants to make an object working on his old OS, he must also be ready to the
drawbacks, this has never been a news.
Afterall, unicows is doing the same job when wrapping the vaious widechar APIs.
But for NT and later, everything just need to be compiled as UNICODE, no?
And this is what I cannot understand: the ability to work in both enviroment is an
*added*value* to the software, not a defect.

I just wanted to clarify that I was not asking to release the accessories and/or other
parts of ReactOS' binaries compiled for ASCII. Absolutely not, in no way!
Read: I want the most flexible international support available.

Just another small bit: besides the functions with the 'W' suffix (while the
remaining part of the planet uses at least the unified function names), sometimes
debugging directly unicode is a  pain, at least for me...
The strings into the debuggers are shown as a vector of words instead of a clear string,
same condition when declaring some constant strings into the sources, as vector of single
chars...
Horrible (urgh!).

Sincerely,

Carlo Bramini

[Ged]

carlo.bramix wrote:

>   But, for an ascii-based OS, it's a compromise for
> getting the 
>  application working because that application, if compiled in that
>  configuration, will work only on Win9x/ME. 
We have no interest in ascii-based OS's, we have no interest in 9x/ME.

>   And this is what I cannot understand: the ability to
> work in both 
enviroment
>   is an *added*value* to the software, not a defect.
Why? ReactOS apps have no value in being built as ASCII. 
ASCII is both rude and prehistoric. Move on, this is the 21st century,
ReactOS is a unicode operating system.
As far as we're concerned Win9x is dead.

>   Just another small bit: besides the functions with the
> 'W' suffix (while 
the 
>   remaining part of the planet uses at least the unified
> function names),
>  sometimes debugging directly unicode is a  pain, at least for me... 
Well you stay on your prefered half of the planet and stop bothering us with
your
ASCII ranting...

I'd hate to see you work with C#, you'd have a fit as it's unicode only.
I have visions of you p/invoking everything to make sure you can still build
your .NET apps as ASCII.

>   The strings into the debuggers are shown as a vector
> of words instead of a 
>   clear string, same condition when declaring some
> constant strings into the 
>   sources, as vector of single chars...
>  Horrible (urgh!). 
Get yourself a decent debugger then, or close your eyes, or give up.


Ged.

















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