by Michael S. Kaplan, published on 2008/03/19 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/03/19/8321717.aspx
Please read the disclaimer; content of Michael Kaplan's blog not approved by Microsoft! In particular, this blog discusses what I think people ought to be doing next in their jobs despite the fact that I have neither authority nor responsibility to make such assessments across (at least) two business units of Microsoft. Therefore, my opinions should always be weighed with that in mind and thus taken with a huge hairy grain of salt -- because even if you agree with me, Microsoft might disagree with both us....
So yesterday, when I blogged Conventional wisdom is retarded, aka What the @#%&* is _O_U16TEXT?, I didn't talk much about what should come next.
By which I mean what should happen now, and how should the collection of mis-statements about what "everyone knows here" should be handled.
The first thing that ought to happen is that the folks in the same business unit as the C Runtime, who are actually linking against versions that have this new and exciting functionality ought to fix problems like the one I noted in Sometimes, the shortcuts give better AND faster results.
It is all well and good to want to avoid hacks, but avoiding core architectures designed to support the scenario sounds like a bad idea. They should update their code to properly handle both the UTF-8 and the UTF-16 case....
Of course the documentation is mostly there for the CRT, but there is a lot of other documentation surrounding best practices in the console that probably ought to be updated.
Now Windows is not in exactly the same boat since they use their own private copy of the CRT names msvcrt.dll in the system32 directory.
This DLL is not the one that shipped in VS 6.0; it is a special version of that file that has picked up much in the way of functionality, features, and bug fixes from the newer versions-- basically anything needed by Windows components.
It isn't documented, but the support is there and so people should probably consider using it in their console applications that care about this type of encoding issue.
And anyone forced to use code like what I put in Conventional wisdom is retarded, aka What the @#%&* is _O_U16TEXT? should really update their code -- this applies to Windows binaries, tests of Windows, and components used to build Windows.
Because as I mentioned yesterday, almost no one is getting this right -- literally no one for _O_U16TEXT and a total of one or two multimedia components for _O_U8TEXT, neither of which write to the console.
The other day someone asked me why I liked meeting with people in other teams and discussing issues. I have to admit that one of the reasons is finding out about things like this that prove our older conception of "best practices" was quite flawed,l and how to improve it in our newer versions!
Maybe STL (or someone from his team) can take on the task of talking to the managed folks using the CRT. For the Windows side, I'm actually on one of the teams tasked with communicating best practices so the OS piece of this has already found the right place to be....
I also have to follow up with some folks about how the console does not have font linking. You see, the console is using Lucida Console, which has no font linking -- and thus by default we do not see the right behavior here when we probably ought to for that Japanese text I put in the sample code.
This blog brought to you by ꀜ (U+a01c, aka YI SYLLABLE BIE)
referenced by