Managed、Native、.NET Framework?
皆さん、あけましておめでとうございます。
昨日（1/8）は、CEST技術セミナー＠名古屋で１セッション、VS2010、TFS2010、.NET4.0等に関する講演させていただきました。ご参加いただいた皆さん、ありがとうございました。参加されていたのは組込み業界の皆さんだったにも拘らず、F#を使っている方が何人かいらっしゃって、ちょっとびっくりです。
参加者の皆さんが一番興味を持たれたのは、おまけで紹介した.NET Micro Frameworkでした。これ、WPFのサブセットのGUI（マルチタッチやジェスチャーを含む）、ファイルシステム、ネットワーク機能を、MMU無の小規模HW上で、無償で使えるミドルウェアなんですね。ソースコードもApache V2.0ライセンスでほぼすべて公開されています。アプリケーションはVisual StudioでC#で開発でき、シミュレータ、実機の両方でソースコードレベルデバッグが出来る優れモノ。是非、使ってみてください。SDKは、https://www.microsoft.com/downloads/details.aspx?FamilyId=77dbfc46-14a1-4dcf-a809-eda7ccfe376b&displaylang=en から、Porting Kitは、https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=16fa5d31-a583-4c0d-af74-f4d5e235d5bc からダウンロードできます。日本でかなり引きが強いので、日本独自のユーザー会を立ち上げようかな、と考えているところでございます。
さて、セミナーやお客様先で良く、.NET とか NativeとかManagedとかっていう用語を何気なく使っているのですが、そういえばWindows系の開発をしたことがない人には馴染みがないんだよなぁと、昨日のセミナーで気付き、じゃぁ簡単に説明してみっかと思い付き、この投稿をしています。
まず、Windowsを使ったシステムでの開発を簡単な図にすると、
こんな感じになります。この図の、Managed Code、Native Codeの部分がアプリケーションや開発者が作るミドルウェアの部分です。この構造は、Windows Embedded CE系でも同じです。
まず、Native Code。これは、OSが提供するWin32API（古くからあるC言語のAPI）や、COM（OSが提供するコンポーネント部品）を使って、おもにVC++を使って開発するものです。メモリ管理（必要なワークメモリの確保や解放）はプログラマーが責任を持って行います。Native Codeはその名の通り？、コンパイルするとCPUで直接実行できるバイナリーコードに変換されます。システムの制御やハードウェアと密に連携する機能（MultimediaやWSD、Sensor ＆ Location、等々）は、Windows OSからCOMでだけ提供されるものが多く、これらの機能をフルに使ったアプリケーションを作る時などはNative Codeでのプログラミングが一般的です。メモリもアドレス指定でアクセスできます。COMはNative Codeでのコンポーネントで、VC++を使って独自に作成して、再利用可能部品として使うことができます。システムフォルダー等を覗くとDLLという拡張子が付いたファイルがありますが、COMはDLL（Dynamic Link Libraryの略）なので、この拡張子の付いたファイルとしてシステム上に存在します。
次にManaged Code。こちらは、.NET Framework上で動作するプログラムです。Native Codeとは違い、CLRというバーチャルマシン上で実行される中間コードにコンパイル時に変換され、CLR上で実行されます。メモリ管理はCLRがやってくれるので、あまり気にする必要はありません。プログラミング言語は、VC++、Visual Basic、C#、F#、その他（Iron PythonやIron Rubyなど動的スクリプト言語）が使えます。.NET Frameworkには、様々な部品が用意されていて、通常のアプリケーションを開発するのに必要な部品がほぼそろっています。加えて、部品群がアッセンブリーという単位でコンポーネント化され、どんなクラスがあって、それらのクラスが何のメソッド、イベント、プロパティを提供しているかという情報（メタデータという）を持っていて、開発環境（Visual Studioのこと）がそれを使ってプログラミングを支援するいろんな機能を提供してくれます。だから、Native Codeに比べて実にプログラムを書きやすい。個人的な体感速度でいうと、数十倍は生産性が違います。特に動的にリソースの確保解放が必要な文字列操作では威力が大きい。ただ、中間コードで動くこと、メタデータを持っていることのために、Native Codeに比べて処理速度は遅く（最近は十分早い気もしますが）、プログラムのサイズは大きくなってしまいます。加えて、メモリのアドレス指定によるアクセスができなかったり、OSが提供するWin32やCOMのすべての機能が.NET Frameworkで提供されてもいないので、濃ゆいプログラムは書けません。ただ、COMやWin32のAPIをManaged Codeで使うためのInterop機能が.NETでは用意されているので、それらをManaged Codeで利用することはできます。この場合、Native Code側でのデータ保持形式とManaged Code側でのそれが異なるため、CLR内で、一々変換（マーシャリングといいます）処理が発生するので、注意が必要。
以上、説明したような特性のため、組込みシステムのようなハードウェアリソースが少ない、CPUパフォーマンスが低いといったような場合は、アプリケーションのどこをManaged Codeにして、どこをNative Codeで構成するかを熟考する必要があります。まぁ、システムのすべてがパフォーマンスが厳しいシステムなんてそうそうないので、一般的には、パフォーマンスを考慮しなければならない基本処理の部分をそれぞれ括ってNative Codeで部品化し、アプリケーションのロジック部分等は、Managed Codeでというスタイルになります。更には、最近のリッチなUIを定義するために、XAML（WPFやSilverlight）を使うのが、最近のWindows系開発のトレンドです。
で、.NET Frameworkですが、これはManaged Codeを書くのに必要なライブラリー群の総称名であり、また、単なるライブラリーだけではなく、それを使ってプログラムを書くためのフレームワークも提供しています。.NET Frameworkには、Windows 7やServer向けの.NET Framework（ふつうFull .NETって呼んだりします）と、Windows Embedded CE系（Windows MobileやWindows Automotive等を含む）向けの.NET Compact Frameworkがあります。後者のほうは、Full .NETのサブセット＋Mobileや特定用途機器に必要な機能という構成です。で、.NET Micro Frameworkですが、これはCompact Frameworkが利用できるハードウェアより更に小規模な組込み機器向けのライブラリ群（Full .NETのサブセット＋Micro Framework特有の機能）を提供しています。Full .NETとCompact Frameworkがライブラリー（及びフレームワーク）そのものをさすのに対し、.NET Micro Frameworkの場合は、ライブラリ（及びフレームワーク）だけでなく、これを使ってアプリケーションを開発するための環境（プロジェクトテンプレートやシミュレータ、コンパイラ）も含めた一式全体の名前です。この辺り、そういう違いなんだよと、ご理解くださいね。
・・・そういえば、.NETテクノロジーを支える、各種仕様CLR（Common Language RuntimeやC#）って、ISOやJISの標準にもなっているって、ご存じ？