Mac OS XのFireMonkeyでUnicodeStringとwchar_t *が合わない

UnicodeStringはchar16_t単位の16ビット配列。
だがMac OS Xがターゲットの場合、wchar_tは32ビット。

なので、
UnicodeString u;
wchar_t wbuf[1000];
wcscpy(wbuf,(wchar_t *)u.w_str());

とするとコンパイルは通るが、Mac OS Xの場合はwbufの値は狂っている。
UnicodeString.w_str()が返す(char16_t *)の文字列を扱うときwchar_t単位の関数はほぼ全てそのまま使えなくなる。
だがchar16_t単位の関数郡はあるのだろうか?
ないのではなかろうか。
自分で作れということか。
なんでこうなったんだろう。
wchar_tが4バイトならUnicodeStringも4バイトに合わせるか、もしくはUncodeStringが2バイトならwchar_tも2バイトに合わせれば良かったのではないだろうか。
まあしょうがないのでchar16_tを使う文字関数群を自作するつもりだ。
char16_t配列とwchar_t配列を相互変換する関数を作る方法もあるが、変換が無駄で速度にも影響が出るだろうしバグりそうだからしない。
コンポーネントがUnicodeStringを使っている以上、バグの元だからwchar_tはソース上から消す。

FireMonkeyでWindowsとMac OS Xで共通のソースにするには、
//wcscpyのchar16_t版のつもり
char16_t *jisaku_char16cpy(char16_t *a,char16_t *b)
{
//なんの役に立つのか意味不明だがstrcpyやwcscpyは第一引数をそのまま戻り値で返す仕様。
//文字列長とかコピー後の末端アドレスでも返したほうが役に立つと思うんだが。
char16_t *r;
r = a;
while(*a++ = *b++);
return r;
}
UnicodeString u;
char16_t u16buf[1000];
jisaku_char16cpy(u16buf,(char16_t *)u.w_str());

Windowsがターゲットの場合はUnicodeString.w_str()に(char16_t *)のキャストをしないとコンパイルエラーになる。
Borland C++Builder6のCLX(ターゲットWindows)と、Kylix3 C++のCLX(ターゲットLinux)もソースの互換があまりなかったが、FireMonkeyも負けずに互換性が無くWindowsとMac OS X共通のソースを作ることは簡単ではない。
それでもObject Cで作れとか言われるよりましだが。