by Michael S. Kaplan, published on 2013/04/09 07:10 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2013/04/09/10409660.aspx
The OutputDebugString function has a long history.
Though perhaps not such a noble one.
Now with most Win32 functions that have string parameters, there is a 'W' version that takes Unicode, and an 'A' version that does not.
In a just universe, each would have a purpose.
It is unfortunate that we don't live in a just universe!
Because the very first thing that OutputDebugStringW does is convert it's Unicode string out of Unicode.
What the hell is the freaking point of this function?
It's like the Petunia Pig of Win32.
And we all know Petunia Pig had no point.
I mean, what was she there for, to make Porky Pig seem more manly?
We all know that Porky Pig is gay!
But now, thanks to the good people in Visual Studio, the GB folks in the PRC may be looking at OutputDebugStringW.
Which could make it the Yoko Ono of Win32.
Sigh.
I'll put a bug in....
John Cowan on 10 Apr 2013 8:54 AM:
Dude, if you are going to be porked by an actual porker, you need to have a heliacal Hershey highway -- which nobody does. So while Porky may be able to fool around with his best buds a bit, for true satisfaction it's home sweet home to Petunia.
WndSks on 10 Apr 2013 12:55 PM:
Having a crappy W version that just converts back to ACP is better than having no function at all when it comes to debugging stuff IMHO, especially back in the 9x/NT split days when you might be compiling both TCHAR versions.
Kalle Olavi Niemitalo on 10 Apr 2013 3:54 PM:
At the debugger side, the OUTPUT_DEBUG_STRING_INFO structure already supports Unicode. I don't know whether the kernel debugging protocols do.
(Have there been any requests for GetProcAddressW? Windows CE apparently has it already.)
Mike Dimmick on 12 Apr 2013 6:00 AM:
@Kalle: GetProcAddress on CE (no W suffix) is a WTF because the strings are all byte-oriented in the PE format, meaning the implementation has to convert back from Unicode to ACP to do its job. According to the documentation, a GetProcAddressA routine was added in CE 3.0.
The CE rule was 'all Unicode all the time' and it led to a few inappropriate conversions. WinMain taking an LPWSTR rather than LPSTR for lpCommandLine is another - kind of sensible for CE, but source-incompatible with desktop/server Win32.
Yuhong Bao on 12 Apr 2013 3:24 PM:
"WinMain taking an LPWSTR rather than LPSTR for lpCommandLine is another - kind of sensible for CE, but source-incompatible with desktop/server Win32."
Not if you use _tWinMain.
Michael S. Kaplan on 13 Apr 2013 2:33 PM:
It's part of why we even Windows 95 had GetCommandLineW. :-)
Yuhong Bao on 14 Apr 2013 10:26 PM:
BTW, I wonder why Win9x did the file system Unicode/ANSI/OEM conversions in IFSMGR, without any way to directly access the Unicode long filename from user mode that I know of?
Random832 on 15 Apr 2013 10:11 AM:
So on Win9x, did GetCommandLineA return the command line in ACP or OEMCP? Was it affected by SetFileApisToOEM (and if so, what mode was it in for passing the argument to WinMain)?
Yuhong Bao on 15 Apr 2013 7:48 PM:
BTW, not related to internationalization, but do you know why some MS05/06 security updates for 9x used KBxxxxxx.exe/Qxxxxxx.dll instead of actually patching the files?