プログラム

Windows アプリケーションに限った話です。

私は、[Windows 95]以来ずっと、32ビット版OS(オペレーティングシステム)を使ってきました。
今調べるとWindows XPにも64ビット版があったようですが、ごく最近までそのことさえ知りませんでした。

Windows 7の発売以来、64ビット版のOSが普及してきましたので、アプリケーションも64ビット版への対応が必要になってきました。

この度64ビット版への対応を勉強しましたのでご報告いたします。

 

マイクロソフトが提供するWindows開発ツールは[Visual Studio]です。[Visual Studio]は32ビットOSでも64ビットOSでも同じように動作します。

[Visual Studio]で32ビットあるいは64ビット用のアプリケーションを作成するのですが、その方法は、ビルドするときにコンパイルスイッチを、[x86]、[x64]あるいは[AnyCPU]の何れかに設定するだけです。

ここでひとつ理解しておかなければいけないことがあります。

Visual Studioでビルドしたものを、ターゲットマシンにインストールするのですが、Visual Studioの出力は、機械語ではなく、[IL]という中間言語だということです。

この中間言語ファイルの中身は32ビット版/64ビット版共通なのです。ただ違うのはこのファイルのREというヘッダに、[x86]、[x64]あるいは[AnyCPU]の異なる情報が付加されていることです。

ターゲットマシンでこのアプリケーションを実行するとき、.NET実行環境は、[x86]ファイルは32ビット機械語に、[x64]ファイルは64ビット機械語に、[AnyCPU]ファイルは、32ビットOSなら32ビット機械語に、64ビットOSなら64ビット機械語に翻訳しようとします。

ターゲットマシンが32ビットOSのときは、64ビット機械語にすることも、実行することもできませんので、64ビット（x64）指定のアプリケーションは動作しません。

逆に、64ビットマシンでは、32ビットプログラムも64ビットプログラムも動作しますので、上の何れのコンパイル（機械語化）も問題ないように思われますが、ここにも問題があります。

通常私たちが開発するプログラムは、自分のコードだけで完結することはありません。マイクロソフトやサードパーティーの様々なプログラム(ライブラリ、Dll)を利用しながら、アプリケーションを開発していきます。

すべてのライブラリのコンパイルスイッチが、同じ設定であれば問題ないのですが、[x86]と[x64]の混在は許されません。

アプリケーションを[x86]でビルドし、64ビットOSで起動しようとしたとき、ライブラリの一つでも[x64]や[AnyCPU]でビルドされていると動作しません。

すべてのプログラムが[AnyCPU]でビルドされたいれば、問題ないようにおもわれますが、ここにも問題があります。

アプリケーションでWordやExcel等のOfficeを使うことがあります。

殆どすべてのユーザのコンピュータ（ターゲットマシン）には、既にOfficeがインストールされ使われています。64ビットOSでも32版のOfficeをインストールできますし正常に動作します。もしユーザの64ビットOSコンピュータに32ビットOffeceがインストールされていると、問題が生じます。

アプリケーションからこの32ビットOfficeを使いたい場合は、アプリケーションそのものを[x86]でビルドしなければ、いけません。

ところが、
アプリケーションで利用したサードパーティのライブラリが[AnyCPU]や[x64]でビルドされていると、64ビットOSはこの部分を64ビット機械語に翻訳しようとしますので、32ビット/64ビット機械語の混在になり、動作しません。

もう一つ考えられる逃げは、アプリケーションはインストールされているOfficeを使わないで、アプリケーションが必要とする[Runtime]を別途インストールすればいいのではないかということです。マイクロソフトは32ビットおよび64ビット[RunTime]を無償で提供していますので、[x64]あるいは[AnyCPU]でアプリケーションを作成しておいて、必要な[RunTIme]をインストールすれば解決するように思われますが、これができません。

すでに32ビット版のOfficeがインストールされている環境に、64ビット版のOffice RunTimeはインストールできないのです。

結局、
「ターゲットマシンが64ビットOSで、32ビットOfficeがインストールされている環境では、Officeとサードーパーティのライブラリを使ったアプリケーションは動作しない可能性が大きい」というのが結論と思われます。

歳をとってきて、「もう勉強してもしょうがないか」と時々思いますが、頭が錆びるのを待っているのも芸がないので、健康に気をつけながら勉強していきたいと思います。

 

私はこのところAccessの仕事をしていました。

大きくもない10万行程度のパッケージソフトを作るとき、DBとしてはAccessが最善だと思っています。

その理由は、AccessRuntimeが走ってさえすれば、Accessファイルをターゲットコンピューにコピーするだけで動作してくれるからです。
万一AccessRuntimeがインストールされていなくても、インストールプログラムから簡単にAccessRuntimeをインストールできます。

一方SQL Serverでは、
ターゲットコンピュータにこれがインストールされていることは殆どありませんので、まずSQL Server Expressをインストールして、次にデータベース（インスタンス）を所定の場所に配置し、SQL Serverに接続しなければいけません。

特定の顧客のためのシステム開発であれば、手作業でこれらをセットアップすればいいので、大して問題ではありませんが、パッケージソフトのセットアップで処理するのは難しいことです。

従って、パッケージソフトの開発にSQL Serverを使うのは躊躇します。

 

前置きのようになりましたが、いっとき私はEntity Frameworkを勉強したのですが、AccessでEntity Frameworkが使えないので、その後Entity Frameworkから遠ざかっていました。

最近、Entity Frameworkの技術が進歩していることを知りました。私が勉強したのは、多分バージョン1だったと思いますが、今はV6がリリースされています。

これまで私が書いていたデータベース・プログラムは小さいものですから、AccessでAdoやLINQを使って、DataBaseを直接操作していました。
しかし、本格的なプログラムとなると、User InterfaceとStorageの間に階層を設けて開発しないと、事が複雑になるといわれています。Entity Frameworkはこのあたりの勉強にはいい教材になりそうなので、今後Entity Frameworkを実務で使うかどうか分かりませんが、もう少し勉強しておこうと思います。

以前購入していた、Larry Tennyの”Entity Framework 4.0 Recipes”を少し読み始めました。問題を解いていく形になっていて、少しずつ分かりやすく解説しています。
数年前、Lermanの”Programming Entity Frameword”という本を少し読みましたが、何故かとても読みにくいものでした。
同じLermanの”Code First”と”DbContext”という本がアメリカAmzonで評判がいいので、買いました。読んでみようとおもいます。

 

これまで何度も書きましたが、パッケージソフトのセットアッププログラムにWixを使いたいと思っているのですが、結構ややこしいし、文献も少ないので、勉強はなかなか進みません。

これもものにしたいと、Nick Ramirez”Wix 3.6:  A Developer’s Guide to Windows Installer XML”(PACKT)
を積読しています。

 

当サイトの引越しをしたいので、Joomla の最新版を勉強して、できるだけ早く移植したいと思います。Eric Tiggeler”Joomla! 3 Begginner’s Guide”(PACK) を勉強中です。

よくあることですが、読もうと思って買い込んで、やがて忘れてしまった本があります。Jennifer Marrriot”The Official Joomla {book}”(Addison Wesley)がそうです。こちらは教科書風というかマニュアル風の書き方です。

一方のEric Tiggeler”Joomla! 3 Begginner’s Guide”は例題に従って、Step By Stepでサイトを構築するように書いています。2冊が補完する形で丁度いいです。

 

これら全部を今年中に読めそうにありませんが、できる限り努力したいと思います。
それから、韓国については一通り勉強しましたので、そろそろ中国について勉強したいと思います。

年を取ったら意識して運動しないと、ついつい運動不足になります。できれば週2回のゴルフの練習と、月2回のラウンドを目標にしています。

余談ですが、ゴルフの平日料金は安くなって、関東のそこそこのゴルフ場でも、昼食付きで6,000円代は珍しくありません。
しかも、高齢者はゴルフ場利用税(800円程度)が半額だったり、全額免除だったりします。
さらに、インターネット申込者本人はプレーフィー無料というケースもありますので、昼食代だけで、一日プレーできる幸運も時にはあります。

私が主に使っているコンピュータは、
およそ4年前に買った[Dell Studo 540]（Vista Home x86）です。
一度ハードディスクを交換しましたが、
静かだし、特に不満はありません。

アプリケーション・ソフトの開発者として「特に不満はない」という意味は、
このコンピュータで開発できないほど大きなプログラム、
すなわち数千万行におよびプログラムは書かないということです。

私がコンピュータを始めたころ、
コンピュータは大変高価で、大きな部屋にドンを座っていて、
夏は大型クーラーが部屋全体を冷却しなければいけない代物でした。

それでも私が初めて使ったコンピュータは16ビットOSだったと思います。
その後「発明」されたパソコンは8ビットOSだったと思います。

8ビットOSということは、何が問題かといえば、
大きなプログラムが書けないということです。

プログラムは最終的に機械語に翻訳されます。

一つの機械語命令は、[オペレータ]部と[オペランド]部からなります。
たとえば[1をアドレスAに保存せよ]という命令では、
オペレータは[保存せよ]、オペランドは[1]と[A]です。

ここで問題は[A]というアドレスです。
アドレス部に8ビット(1バイト)使うと、指定できるアドレスの数は256です。

1ビット　2
2ビット　4
3ビット　8
4ビット　16
5ビット　32
6ビット　64
7ビット　128
8ビット　256

すなわち、8ビットOSでは機械語に落ちた時のプログラムの大きさは最大256行です。

こんな小さなプログラムもパソコンが出現したときは、
みなさんはそれなりに有効に使っていました。

16ビット（2バイト）で約6万、32ビット（4バイト）で約4G（ギガ）の大きさのプログラムが書けます。
アプリケーションの開発では、16ビットコンピュータは時に小さすぎますが、
32ビットコンピュータは普通のプログラム開発では十分です。

上の議論は正確ではありません。
アドレスがバイト(8ビット)の先頭を指すのなら、
上の数はアドレスが指し示すバイトの数です。

私が機械語(アセンブラ)の勉強をしたのは昔のことで、
現在の命令がバイトをさすのかワードを指すのか知りません。

ただ、ここではアドレスの大きさが、指し示すことのできるアドレスの数の上限を決めている、
そしてバイト数による上限が幾らかを理解しておけばいいと思います。

しかしOSの立場からすると、ハードディスクは今や数テラバイトの大きさは普通になってきましたし、
大きなプログラムが何本も走ることはこれからますます増えて、
メインメモリも4Gを超えてきました。
OSは4Gを超えてメモリを管理しなければいけません。

という訳でアプリケーション開発からは必ずしも必要ないのですが、
OSのメモリ管理の立場から64ビットOSが必要になってきました（そう理解しています）。

 

前置きが長くなりましたが、
そんな訳でアプリケーション開発者である私は、64ビットOSにあまり関心がありませんでしたが、
気が付くと、世の中どんどん64ビットOSを採用しています。

私が作っているパッケージソフトも64ビットOSで動作させる必要に迫られてきました。

64ビット版パッケージソフト作成に取り掛かりました。
まず、64ビット[Windows 8]に[Visual Studio 2012 Premium]と[Office 2010]をインストールし、
この上に32ビットVistaで開発したプログラムをコピー、コンパイルしました。

意外にもコンパイルまではすんなりいきましたが、
動作させるとエラーがでます。

実はこのプログラムはデータベースにAccessを使っています。
色々試行錯誤して分かったのですが、
まず、64ビットOSには64ビットOfficeをインストールしなければいけません。
Officeを単独で使う分には32ビット版をインストールしても使えますが、
64ビットアプリケーションから32ビットAccessをコールすることはできません。
ビルドでターゲットコンピュータを32CPUと宣言すれば動作しますが、
そもそも64ビット用アプリケーションを作成しようとしているのですから、論外です。

今問題を拡大したくなかったので、
32ビット版の開発環境に近づけるために、
別のコンピュータに[Windows 7 x64]をインストールし、
32ビット版と同じ[Visual Studio 2010]と[Office 2010 x64]をインストールして、
Accessファイルも新たに作った64ビットAccessにインポートしました。
（[Visual Studio 2010]そのものは32ビット製品のようです）

ビルドして、64ビット版アプリケーションが完成です。

 

つぎはセットアップ・プログラムです。
出来上がったアプリケーションソフトをユーザのコンピュータにインストールしなければいけません。

私は、ずっとセットアッププログラムに悩まされてきました。

私にとってのセットアッププログラムの必要条件は、
①　プロダクトキーによるソフト管理
②　ターゲットコンピュータにAccess Runtimeのような、
アプリケーションで必要なソフトが既にインストールされているかどうか検査し、
インストールされていない場合は自動でインストールする仕組み
③　Patch。
プログラムの更新で、変更部分だけの差分インストール

等です。

セットアップで一番簡単で確実なツールは、
[Visual Studio]に添付されている[Setup Project]プログラムですが、
これは上の条件の何れも満足しません（②は不十分です）。

セットアップソフトとしては、InstallShieldが一番いいのでしょうが、1本数十万円しますし、
OSが変わるとその都度バージョンアップしなければいけません。
私の立場からすれば、コストパフォーマンスの点で不採用です。

数年前、比較的安価なInstallAwareというセットアップソフトを購入したのですが、
このソフトは不具合が多いし、頻繁にバージョンアップします。
バージョンアップでなにが変わったのか分からないのです。
むしろ「バグ取りしただけだろう」といいたいくらいで、
機能的にはいいのですが不信感をもっています。

 

なので、WIX（Windows Installer XML Toolset）を使いたいのですが、
ドキュメントが少ないし、開発が遅い。
「本気で普及させる気があるのかな」と疑うほどです。

今は次のように考えています。
（何れも、32ビット版と64ビット版が必要です）

デモ版は、、[Visual Studio]に添付されている[Setup]プログラムを使う。
製品版はなんとか、InstallAwareの機嫌を取りながら使う。

幸い、WIX3.6では先の②に相当するBootostrapの機能がついたので、
将来のためにWIXを研究する。