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
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: +44 (0) 870 8368770 f: +44 (0) 870 8368701
Registered in England No 4760795
-
carlo.bramix -
Ged