相変わらず日付間隔が開く日記です。ま、プログラムの情報を書いているだけなので飛んでも注目されないだけいいのですが・・・。

今やっている作業は、自分が作ったソースの変更移植です。つまり、

• ASCII(SJIS)コードになっていたものをUNICODE(または両対応)のソースへと変更
• 32bitで動いていたコードの完全64bit化(内部実行機関)

です。

ベースライブラリはすでに両方のコードコンパイルに対応しているので後は本体プログラムだけです。

UNICODEへと対応させるときは、以下の点に注意します。

• 文字列を扱うときはcharではなくTCHARもしくはwchar_tを使用する
• 文字列処理ライブラリをtchar準拠のルーチンを使用するかwchar_t準拠のルーチンを使用する
• 文字列、文字コードを_TマクロやTEXTマクロなどで囲ってコンパイラに認識させる
• 元々マルチバイト文字処理を行っていた部分のスキップ処理に注意する
• STLを使っているときはstd::stringからstd::wstringへと処理を変更して、sizeメンバ関数の戻り値に注意する
• char型しか使えない関数(GetProcAddressなど)で文字コードを間違えないようにする

ここで、意外と問題になるのが「文字コードを_Tマクロで囲う」です。これはコンパイラでは警告が出ない(charを自動的にwchar_tへと(整数型的に暗黙で)変換できるため)ので、

がんばって検索をかけて調べる必要があります。一括置換でも問題はないですが、これをやるとcharで書かなければならないルーチンで以外とミスったりします。悲しいです。

文字列の場合はほとんどの場合先にコンパイルエラー(char *とwchar_t *は暗黙に変換できない)となるのでコンパイルテストを行うだけでほぼ問題がなくなります。

ただ、ほとんどの半角記号ではASCIIコード==UNICODEなので、書かなくても「ほとんどの場合でコードが正しく動いてしまう」ということで。

ま、linuxなどの移植を考えると完全にUNICODE化するのではなく、UTF-8への準拠も考えてコードを組んだ方が安全です。

「Windowsだけでいいや」というのであれば、今の時代ならASCIIベースで組むことの意味は勉強用のプログラムであること以外では意味がないと思います。

そろそろプログラムネタの連載をやってみたいな～と思います。今やるなら実行ファイルネタでしょうか・・・。

あと、WindowModePatchの対応ができないゲームをかなりの数確認し始めたので対応を考えてみたいと思います。