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