PathRemoveFileSpecAに0x5cを含むパスを渡した時の挙動

PathRemoveFileSpec function (Windows)
Shell Lightweight Utility FunctionのうちのPath系のFunctionは便利で私もよく使っています。PathRemoveFileSpecのANSI版が特定のOSでバグっているという話を聞いたので、試してみました。

#include <stdio.h>
#include <windows.h>
#include <shlwapi.h>
int _tmain(int argc, _TCHAR* argv[])
{
  TCHAR szPath[_MAX_PATH + 1] = _T("c:\\temp\\表示\\性能評価表(圭一).csv");
  TCHAR szSource[_MAX_PATH + 1];

  lstrcpy(szSource, szPath);
  PathRemoveFileSpec(szSource);
  _tprintf(_T("PathRemoveFileSpec:%s\n"), szSource);
  return 0;
}

Visual Studio 2005以降で試すときは必ず文字セットを「マルチバイト文字セットを使用する」に変更してください(既定はUnicodeです)。ご存じのとおり、「表」や「圭」はShift-JISで表現した場合、0x5cを含みます。Windows 7 x64で実行するとこうなります。

正しい結果です。これをWindows Server 2008 SP2で実行するとこうなります。

32bit/64bit関係ないようです。当然ですが、Vistaでも同じ結果です。Unicodeは大丈夫のようです(といっても、渡す文字列がUnicodeなので当たり前なんでしょうけど)。ANSIのままのプロジェクトがこのAPI使っていたら、文字列をUnicodeに変換して、明示的にPathRemoveFileSpecWを呼び出して、またANSIにするなんていうめんどくさい手順を踏まないといけないでしょうね。
上のソースではコンソールへのUnicode出力なんて考えていないので、そのままUnicodeで実験すると化けますんで、気を付けてください。