処理系の選択に付いて	- 補足 -			2001.March/2002.April

1. まえがき
　大事なことを忘れてました。処理系の選択の際に考えておく必要のある事項が
　まだあります。

　で、その話をする前にWindowsでプログラムが実行される時の仕組みに触れないと
　なりません……。

2. Win32プログラムの実行
　+----------------------+
　|Win32アプリ           |
　+----------------------+
　+-----------++---------+
　|Windows API||C Runtime|
　|           |+---------+
　|           +----------+
　|                      |
　+----------------------+
　+----------------------+
　|Windows OS            |
　+----------------------+
　fig.2.1 「Windowsアプリの実行中」の図

　ここでWindows APIっていうのは、MessageBox()とかlstrcpy()とかという、
　Windowsでしか通用しない関数のこと。
　kernel32.dllとかshell32.dllとか...要はC:\Windows\System\*.dllの類は
　こうしたWindows APIがちょっとづつ分割されているものだ。と、とりあえず
　理解しておけば良いです。

　何故、あんなに細かく分かれているかと言えば、全く使用しない関数が
　含まれたdllはメモリにロードしなくて済むじゃん？

　ってことですね。
　んで、dllはダイナミックリンクライブラリの略です。実行時にdllがロード
　されます。って仕組みです。

　プログラム起動時に「実行に必要なうんちゃら.dllが無いよぉ(T_T)」とか
　言われたこと、ありませんか？

　ちなみに「ほげほげ.dllに欠陥エクスポートニャオがあります」って言われた
　場合はご愁傷さま。MSのいう「Dll hell」です。同じ名前の違うバージョンの
　(おそらくより古い)dllがシステムにインストールされてしまってます。

　インストールの順番を間違うとこうなることがあります。ご注意。って、より
　新しいdllが問題起こすこともありますけどね。

　こうなったらもうお手上げ。下手にあがくよりWindowsの再インストールが
　吉です。ハイ。
　WinMEとかにあるOSの修復機能はどーかとゆーと、使ったことないので分かりま
　せん(^^;;

　ところで、このdllのうちにC Runtimeライブラリがあります。これは何か。
　というと、C専用のサブルーチン群です。strcoy()だのfprint()、fopen()の類。
　ANSI Cとして決められた関数群です。
　(他にもプログラムの開始処理や終了処理もあるはずだがはしょります)

　C RuntimeがWindows APIの*上*に載っかっているのは、ANSI Cのfopen()とかは
　結局WIndows APIであるCreateFile()とかで処理されるはずだからですね。
　(多分、ね)

3. C Runtimeの問題
　ちょっとだけ以前でも触れてますが、処理系により使うC Runtimeが違います。
　自分のマシンで使うだけなら、これはどうでも良いことです。しかし、できた
　*.exeを他人に配布しようとした場合に問題となります。

　作成に使用したコンパイラがインストールされていないマシンでその*.exeを
　動かそうとすると「プログラム開始エラー」とか言われることになります。

　コンパイラやリンカのオプションで「RTLを使用する」「ダイナミックリンクする」
　とかいうのを指定するとこういうことになる場合があります。
　(RTL = Run Time Linraryの意味)

　でもだからと言って「スタティックリンクする」とかを指定するとできた*.exeが
　馬鹿でかくなってしまいます。
　dllにある機能が片っ端から.exeにくっ付くんで、これは当然。メモリとHDDの
　無駄。ということです。

　この辺りはトレードオフ(あちらを立てればこっちが立たず)です。

　DLLの長所、「どうせ同じなんだからみんなで共有して幸せになろうよ。」が
　裏目に出た格好ですね。

　こういう意味だとbccは辛いです。16bit時代のbccはかなりメジャーな存在でした
　から、bwcc.dllは雑誌の付録とかにも良く付属してましたが……。

　＃bwcc.dllは16bitなbccのランタイムであって、32bitなbccとは無関係

4. トレードオフのまとめ
　以下にそれぞれの処理系の優劣を記します。どの処理系を選ぶかはご自身で決めて
　下さい(あくまで主観的データなので、そのつもりで)。
　＃注意：bccはあくまでフリー版の話。市販のbcbのことではありません
　＃VCはVC6 SP5の話です

			優れている(問題なし)		劣っている(問題あり)
コンパイル速度		lcc		bcc/vc++(*1)	gcc
実行ファイルサイズ(C)	gcc/vc++	lcc		bcc
実行ファイルサイズ(C++)	vc++		bcc		gcc	(*2)
ランタイム問題		lcc/gcc		vc++		bcc
HDD占有サイズ		lcc		bcc	vc++	gcc
入手価格		lcc/gcc/bcc			vc++
日本語の使用		vc++/bcc	gcc(*3)		lcc
統合環境		vc++/lcc	gcc(*4)		bcc
MFCの使用		vc++				lcc/bcc/gcc
情報の豊富さ(ユーザ数)	vc++		gcc(*5)	bcc	lcc
html helpの使用		vc++				gcc/bcc/lcc(*6)
ヘッダファイルの信用度	vc++(*13)/bcc	gcc/lcc
vc++との互換性		vc++	bcc		lcc	gcc
ワイルドカードの展開	vc++/bcc	gcc(*7)		lcc(*8)
Windowsバージョン依存			vc++/bcc	gcc/lcc(*9)
*.VxDの作成		vc++				gcc/lcc/bcc
glut32によるOpen-GL	vc++	lcc	gcc		bcc(*10)
統合環境		vc++	lcc(*11)	bcc/gcc(*12)

(*1) vc++の方が若干速いかも
(*2) lccはC++をコンパイルできないので論外
(*3) gcc自身を再コンパイルすればOK
(*4) 自分でパッケージを探して下さい。私は知りません
(*5) Windows上では。という条件付きです(多分こんなもんでしょ？)
(*6) どうもhtmlhelp.libって、スタティックライブラリのようですね。ダイナミック
　　 ライブラリならどうにでもできるのですが……。昔の*.hlpなら簡単なのですが、
　　 *.chmを扱うにはvc++でないとダメっぽいです
(*7) gccは常に展開します。抑制はできない気がします(私が無知なだけかも)
(*8) lccはWin95とWin98で異なる挙動をします。制御はできません。95では展開します
　　 が、98では展開しません
(*9) WinバージョンやIEに依存する関数のサポート。という意味です。APIによっては
　　 WindowsバージョンやらIEバージョンとかを判断して色々細工しないとダメ。
　　 個人的にはWin95 OSR2 + IE4以降を仮定。で、もう良い気がします。
　　 (それ以降でないと検証もできない。という事情もあります)
(*10)main()で開始する、GUIなプログラムのリンク方法が分かりません＜bcc
(*11)16*16*16なアイコンが作れないってのが痛い
(*12)あっしが知らないだけかも。特にgcc
(*13)Platform SDK付属のヘッダで最新版にした場合の話。生のVC++のヘッダは古過ぎる。
　　 ちなみにbccにはほぼ最新版のMS純正ヘッダが付属してたりする

＃ブラウザの解釈の関係でtabがずれてわけわかかも。まぁ、目安なので……

(EOF)