>>365
励ましありがと～。どうも、最近になって諦め癖がついてたようです。

まだ調査継続中ですが調査の中間結果を…
GetWindowText()が変更するバイト数は、［S-JISでの入力バイト数*2+2］（最後の+2はNULLかも）
どうも、リッチエディット(以下Riched)のフォントはUNICODEでも、実際にRichedが保持している
文字情報はS-JISっぽい？

で、私見ですがWin98SEにMSLUを使用した場合のGetWindowText()内部は、
Richedに入力されたS-JISのデータを（制御コード含め）「そのまま」にUNICODEに読み替える。
　↓
読もうとして読めたやつはその文字コードで固定。読めなかったやつは、"?"[0x003F]に変換。
S-JISで換算して奇数Byteの入力の場合、1Byte余るので[0x00]をくっ付けてそのままUNICODEに。
　↓
そうすると、変更予定バイト数に明らかに足りないのでそこは[0x0000]で埋める。

こんな感じかな。そうなると大半の出力が"?"だけになるのとも合致する。
それと実験して見つけた実証パターンとして"0テf"[36-83-65-66]を入力すると
"茶晥"[36-83-65-66]とでるので、部分的に違うところがあっても完全に間違いではないと思う。

逆にこれが本当だとすると、使い物にならないと言う結論が出そうで怖い…（；´д⊂

-------------
…と、ここまで書いて>>367さんの書き込みを発見。
で、それを使ったら入力は一発で出来ました。ヽ(￣▽￣)ノ
ありがとうございます。

結論：
　MSLUの実装するGetTextWindowW()など、ウィンドウからテキストを取得する関数は
　UNICODEに対応してない！

さて、次は多言語表示だな…。とりあえず、>>366さんの発言を見てフォントを
DLしましたがダメでした。コントロール系はまだ試してません。

長々と書いてしまって、すみません…