前回、突然メモリ不足になって焦ったわけだが、
冷静になって解決法を考えてみた。
解決法1. 無視する
空きメモリが減ってくると、それ以上使えないってことで、メモリを使うのを諦めるらしい。
フリーズしなければ（運が良ければ）終わるってことか。
解決法2. 32bitのchkdsk使う
とりあえず、今はこれで解決ということにしている。
GUIからやる方法は知らないので、とりあえず管理者モードでコマンドプロンプトを開いて、
C:\Windows\SysWOW64\chkdsk.exe [対象ドライブ] /r
これなら32bitアプリケーションなのでメモリが制限される↓ 
こうすればchkdsk中にブログ書いたり、音楽聴いたりしていてもメモリ不足と怒られたり止まったりする心配はない。
しかし、スゲー時間かかるのは仕様ですかね。
…
chkdsk.exeに5GB強のメモリを占拠されてこうなった。
Windows 7 RTM版に「深刻なバグ」の指摘
～CHKDSK実行でOSがクラッシュ、開発責任者は火消しに躍起
とりあえず、RTMから直ってないのかどうかは知らないけど、
何度やってもメモリが足りなくなる。
4GB以上のメモリを消費しているところを見て、さすが64bitなんだなーって実感したけど、
これは普通に困るから何とかして欲しいわ。
（もうすぐ出るらしいSP1に期待）
.NETのアプリが動作モードが32bitか64bitかというのは
ビルドするときに立てたフラグからx86/x64の動作を決めているらしい。
x64で本格化する64ビットWindowsの時代(5) – ITレポート（動向／解説）：ITpro
ビルドするとき[Any CPU]にしていると、32bit環境なら32bitで、64bit環境なら64bitで動作する。
ならそんなわけで、ちょっと前の.NET 2.0が主流だった頃のアプリケーションは64bitを意識せずに作っているわけでもないのに、64bitで動作していたりする。
中にはunzip32.dllみたいなモジュールをロードしようとしたりしてエラーみたいなことになったりする。
解決方法としてはWOW64上で32bitとして動かせばいいというだけなんだが、
とっくの昔に開発を終了しているソフトをコンパイルし直せとか作者に求めるのは無理なので、
Windows SDKに入ってる「corflags.exe」を使って、PEヘッダーを書き換えることにした。
…
64bitに移行したのはいいけど、PCが不調なのは相変わらず。
原因はマザボなんだろうけど、今は確実に買い時じゃないのでとりあえず（今月は）耐えることに。
さてー。
Windowsの64bit環境だと、それまでの32bitアプリはProgram Files (x86)にインストールされる。
普通の使い方をしていれば問題ないのだろうけど、32bitのとき開発していたプログラムとかのプロジェクトファイルのライブラリのリンク先は「Program File」内となっているのものがほとんどだったりする。
それで、プロジェクトを開くとmissingエラーが続出するから面倒。
適当なバッチとかで全部書き換えるのも考えたけど、逆に32bitのラックトップで開発するときに困る。
そんなわけでとりあえずな対策としてシンボリックリンクを使った。
>mklink /D “C:\Program Files\XXX” “C:\Program Files (x86)\XXX”
という感じで。
しかしもっとスマートな方法はないのかなぁ
