04 VS.net製のプログラムはどぅして動くのか
検証環境 自作ATX(Cerelon533/VT6X4/384MB)
Windows2000ProSP2/IE6.00Jp/VS.netB2J
マシン語だから。
すいません、嘘です。VS.netに含まれる言語で作成したプログラムは、基本的にはマシン語になりません。
じゃ、なんになるかというと。MSIL(Microsoft Intermediate Language)と呼ばれる中間コードになります。
中間コード。
VBでプログラミングしてきた方にはおなじみの響きですね。
今回はMSILと呼ばれるようになったんだ。
ぶぶー。これは間違いです。どぅも今までの技術と1対1で紐づけて把握できる構成ではないようですよ。
まず、VB6でのVB/VC++の開発から実行までの構成を思い出してみてください。
おおまかな構成は以下のような感じです。
上の図は、Visual Studio 6の開発フェーズにおける各プログラム/ファイルの関連の概念図です。単独実行ファイル(.EXE)としては、まぁこんな感じになるわけですね。
VBでは、ソースを書くための機能(IDE)と実行ファイルを作るための機能(コンパイラ)が同じひとつのプログラム(VB6.EXE)にまとめられています。ですから開発者は、ソースの書き始めから実行ファイルの作成までをひとつのプログラムの中でシームレスに行えます。
また、VB6.EXEは大まかに2種類の実行ファイルが作成できます。p-code(中間コード)とネイティブコード(マシン語)ですね。
一方VC++は、ソースを書くための機能(IDE)と実行ファイルを作るための機能(コンパイラ/リンカ)が分かれています。
コンパイラは単にソースをマシン語に置き換えるだけの作業しか行わず、これをいろんなWindowsファイル(やそのライブラリ)と組み合わせて実際にWindowsOSから動作を開始できるような実行ファイルに編み上げるためのリンカというプログラムが別に存在します。
ですから実行ファイルを作成することをコンパイルとは区別してビルド(コンパイル & リンク)と呼びます。
まぁ実際にはIDEからでもビルドはできるんですが、これはIDEがコンパイラ/リンカを呼び出しているんですね。
VC++が作成できる実行ファイルは、こちらも大まかに分けて2種類。MFC(VC++用ライブラリファイル)を別に必要とするタイプと、MFCが不要・もしくは自分自身の中に埋め込まれて単体ファイルで実行できるタイプですね。
今度の図は、VS6で作成したプログラムの実行フェーズにおける各プログラム/ファイルの関連の概念図です。
VB/p-codeの場合EXEそのものは中間コードなわけですから、これを解釈・実行する実行エンジンが別途必要になります。これをVBランタイムと呼びます。ですからp-codeプログラムの場合、実際に動作するマシン語はランタイムのそれであり、EXEファイル自体は実行手順を格納したデータファイルという扱いになります。
VB/ネイティブコードの場合は、一応動作手順はきちんとソースを元にマシン語化されたコードとして格納されていますが、実行中に使用する関数などの大部分はVBランタイムの中のコードをサブルーチンのように呼び出す形式を取っています。
ですので、p-codeにせよネイティブコードにせよVBランタイムは必須なわけですね。どちらが主か従かの違い程度です。
VC++ではすべてマシン語コードとして実行ファイルを生成します。
もっともMFCを外部に必要とするタイプのプログラムの場合は、配布ファイルの大きさやインストールの煩わしさはVBと大差ありません。
もちろんVC++で作ったプログラムの方がVBで作ったプログラムよりも、ふつー高速に動作します。 ざっと理解していただけましたか？
厳密に説明しよぅとするともっとあれこれ噛んでくるんですが、まぁ大ざっぱな理解としてはこの程度でいいのではないかと。
配布形態をどぅしよぅとか、より高速な/コンパクトなコード提供をどぅしよぅかと悩む程度であれば、まずはこのくらいのレベルで把握していれば考え出すことはできるわけですし。
今度は、VS.netです。
VS.netの開発から実行までの構成はこんな感じになってるようです。
まずIDE部分が、VB.netをも取り込んで1本のプログラムにまとめられました。
もちろん使用する言語によっていろいろ作業手順は異なりますが、まずオペレーションが統一されたのは大きいです。
また、デバッグがむちゃくちゃ楽になります。
さらに、どの言語を使ってもビルド後に生成される実行ファイルはMSILです。
実は、唯一C++だけは従来のマシン語コード実行ファイルを生成できます。これができないとデバイスドライバやらの低レベルな実行ファイルが作れなくなっちゃうので、ここんとこは残されて当然だと思います。
Microsoftとしては、もはやマシン語コード直書きはWindowsアプリケーションのスタンダードスタイルではない、といぅスタンスのように見てとれますね。
まぁ作成される実行ファイルがすべて同規格のMSILなんですから。実行フェーズとしては当然言語に依存しない単一の環境を用意しておけばいいわけなんですけれども。
このMSILファイルが実行時に少しずつマシン語にコンパイルされながら実行されます。
このへんちょいとややこしいんですが、呼び出される機能単位で必要になったつど(JIT：Just In Time)コンパイルされながら、CLR(Common Language Runtime)の管理下で動作していきます。
大ざっぱに言うと、使っている最中にコンパイルされながら動くプログラム形式なわけです。
…これ、けっこぅ効率の悪い方式のような気がするんですが。…まぁこのへん、もぅちょいいろいろ調べてからまた項を改めて説明したいと思います。
とりあえずここまでの説明で、従来のVSと今回のVS.netはかなり動作までに関わるプログラムや仕組みが違ぅっぽいってことがおぼろげにイメージいただけたかと思います。
で。
配布先でネイティブコードにコンパイルされるための
2次ソースファイルと捉えるべきである。
ってことですね。
CLRも、VBのランタイムといぅよりは、VC++のMFCライブラリとOSのメモリ管理・セキュリティ管理機能を併せ持つといぅややこしい位置付けと捉えた方が正確っぽいです。