.NETアプリを64bitOSのWOW64上で動かす

/ PC / , ,

.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ヘッダーを書き換えることにした。

…

.NETアプリを64bitOSのWOW64上で動かすもっと読む »

64bit環境とパス

/ PC /

64bitに移行したのはいいけど、PCが不調なのは相変わらず。
原因はマザボなんだろうけど、今は確実に買い時じゃないのでとりあえず（今月は）耐えることに。

さてー。
Windowsの64bit環境だと、それまでの32bitアプリはProgram Files (x86)にインストールされる。
普通の使い方をしていれば問題ないのだろうけど、32bitのとき開発していたプログラムとかのプロジェクトファイルのライブラリのリンク先は「Program File」内となっているのものがほとんどだったりする。
それで、プロジェクトを開くとmissingエラーが続出するから面倒。
適当なバッチとかで全部書き換えるのも考えたけど、逆に32bitのラックトップで開発するときに困る。

そんなわけでとりあえずな対策としてシンボリックリンクを使った。

>mklink /D “C:\Program Files\XXX” “C:\Program Files (x86)\XXX”

という感じで。
しかしもっとスマートな方法はないのかなぁ

そんなわけでSSD その2

/ PC

とりあえずBSoD出さずに出来たのでベンチ・・・。
 
微妙。たぶんPCIe x1のスロットはPCIe 2.0じゃないんだろうってことで。
次はPCIe x16の方に差してみる。

無駄に3-way SLIとか対応したM/BだからPCIe 2.0 x16が3slotあったりする。
image  
そんなわけでPCIe 2.0 x16に繋いだ結果
 
おお。ちゃんと300MB/s超えた。
しかし、実際OSを入れるとなるとM/Bにするか拡張カードにするか悩むなぁ。