ビット、フレーム、リンク

  • [アーティクル]

Bobby Schmidt
Microsoft Corporation

先週は喜びと悲しみが交錯した一週間でした。私は両親の結婚四十周記念日に当たる 8 月 6 日にアニーと結婚しました。翌朝、私は父とともに母の亡骸を埋葬しました。

一身上の都合から長期休暇をとったため、このコラムの執筆に取り掛かるのが遅れてしまいました。しかし皆さんにとってはコラムのタイミングが遅れた方が良かったかもしれません。何しろ、多くの皆さんが長い間待ち望んでいたものを Microsoft がとうとうリリースしたからです。

予測が的中

前に予測したように、.NET Framework SDK のテクノロジ プレビュー版を Web から無料でダウンロードできるようになりました（https://msdn.microsoft.com/code/sample.asp?url=/msdn-files/027/000/976/msdncompositedoc.xml）。PDC の会場で配布した SDK とまったく同じものだという触れ込みです。本当にまったく同じものであるか私には断言できません。しかしマニュアルには PDC への言及があり、インストールされたファイル群も同じもののようです。

ファイル容量が 86MB もあるので、56K モデムではダウンロードに非常に時間がかかります。ダウンロードする前に、あらかじめ内容を知っておいた方がよいでしょう。SDK のファイル リストがないか探しましたが見つかりませんでした。しかし SDK のマニュアルを丹念に読み、インストール後のディレクトリを確認した限り、以下のものが含まれていることはほぼ間違いありません。

  • 各種のコマンドライン コンパイラ。Visual C++®用（cl.exe）、C# 用（csc.exe）、JScript®用（jsc.exe）、Visual Basic®用（vbc.exe）があります。C++ コンパイラは新しいマネージ拡張を認識します

  • 各種サンプル（C# で書かれたものを多く含む）とそれをビルドする nmake.exe

  • 上記のコンパイラとサンプルをサポートする .NET Runtime と .NET Framework

  • おなじみの link.exe

  • コマンド ライン デバッガ（cordbg.exe）と GUI デバッガ（dbgurt.exe）

  • IL（Intermediate Language：中間言語）のアセンブラ（ilasm.exe）、逆アセンブラ（ildasm.exe）、バリデータ（peverify.exe）

  • そのほか、アプリケーションの設定と導入、WinForm 設計と表示、セキュリティ管理、JIT 管理のための豊富なツール

  • ランタイム、フレームワーク、ツール、言語に関する詳細なマニュアル。添付マニュアルの量と質は圧巻です。

重要な未添付アイテム

  • Visual J++®

  • Visual Studio®。したがって、エディタ、統合型デバッガ、統合型ヘルプがありません（この制限はある程度まで回避できます。詳しくは後述します）

  • Microsoft によるオンデマンド製品とサポート

私が知る限り、サポートは一般のニューズグループに頼るほかありません（下記の「参考情報」をご覧ください）。しかしそれも仲間同士のサポートや折に触れての Microsoft の書き込みに限られます。

インストールのための環境条件

SDK をインストールするには下記の環境が必要です。

  • Windows 2000。Internet Information Services（IIS）を含む。IIS がなく Windows 2000 をセットアップ済みの場合は、コントロールパネルの［アプリケーションの追加と削除］から IIS を追加できます。 IIS なしで SDK をインストールすることもできますが、その場合 SDK サンプルの一部はビルドできません。

  • Internet Explorer version 5.5 （https://www.microsoft.com/windows/ie/download/ie55.htm）。Internet Explorer 5.5 がインストールされていないと、SDK をインストールできません。

  • Microsoft Data Access Components (MDAC) version 2.6（https://www.microsoft.com/data/download_260rtm.htm）。MDAC がなくても SDK をインストールすることもできますが、サンプルの一部を実行できなかったり、フレームワーク コンポーネントを呼び出せなかったりする場合があります。

幸い、私がインストールしたマシンはまっさらな状態のものでした。まず上記の順番でソフトをインストールしたのち、最後に SDK をインストールしました。

SDK ファイルは主に次の 2 つのディレクトリにインストールされます。

  • C:\Program Files\NGWSSDK。このディレクトリは .NET Framework と、コンパイラなど .NET を動かす各プログラムのホームのようなものです。この場所はインストール時に指定することができます。

  • C:\WINNT\ComPlus\v2000.14.1812（C:\WINNT がシステムのルートディレクトリということを前提にしています）。2000.14.1812 は日付とビルド番号を記号化したものです。これは、複数の .NET バージョンを並べてインストールできるようにするためです。このディレクトリには、各種ツール、C++ 言語のインクルード ファイルとライブラリ ファイル、マニュアル、各種サンプルが含まれています。なお、インストール時にこのディレクトリを指定することはできません。

この SKD は故障しても困らないコンピュータにインストールしてください。通常の仕事用にメインに使っているコンピュータにはインストールしないでください。また、Windows 2000 以外の OS では試さないでください。Windows NT 4.0 も好ましくありません。あなたの友人が、「友達はインストールできたよ」と言ったとしてもです。

私たちはこのダウンロード版をテクノロジ プレビューと呼んでおり、無料で配布するにはそれなりの理由があります。これはあくまでも試用段階の製品であり、皆さんの学習用として提供するものです。企業の情報技術部門などが全社的にインストールするような性質のものではありません。その点を理解した上で使用してください。

Visual Studio IDE との統合

Visual Studio 6.0 Integrated Development Environment（IDE）をお持ちの方は、コンパイラ、ライブラリ、その他のツールを除いた IDE をインストールすることをお勧めします。IDE を使えば、C# ファイルの編集、C# コンパイラの作成、C# コンパイル時エラーの逐次検証が行えます。あいにく、Visual Studio セットアップ プログラムには IDE を単独でインストールするオプションがありません。次善策として、次の方法があります。

  • Visual Studio セットアップを起動してから、通常のインストール手順に従う。

  • オプションが選択できる場合は、標準インストールではなく、カスタム インストールを選ぶ。

  • 「**Visual C++ Developer Studio」**以外はダイアログ内のオプションのチェック ボックスをすべてオフにする。

  • ［続行］を押して、インストールを完了する。

インストールによって目的の IDE のほかに、必要のないもの（ヘッダー、ライブラリ、チュートリアル、その他のツール）まで一緒にインストールされてしまいます。これらは主に新たにインストールされた VC98 ディレクトリに入っています。このディレクトリは削除しても構いません。

C# の処理をできるだけシームレスに実行できるように、IDE のツールバーにユーザー設定ツールを追加する必要があります。カレントの C# ソース ファイルをビルドし、ビルドされたプログラムを実行するためのユーザー設定ツールを作成するために、次の手順を実行してください。

  • Visual Studio 6.0 IDE を起動します。

  • ［ツール］メニューから［ユーザー設定］ を選択します。

  • ［ユーザー設定］ダイアログ ボックスで［ツール］タブを選択します。

  • ［メニュー項目］リストの一番下までスクロールし、一番下の空白行を１回クリックします。

  • 空白行に「**C# &run」**と入力して Enter キーを押します。

  • ［コマンド］フィールドに「**cmd.exe」**と入力します。

  • ［引数］フィールドに「**/c csc "$(FilePath)" && "$(FileName)"」**と入力します。

  • ［アウトプット ウィンドウを使用］ボックスをチェックします。

この手順を正しく実行すると、ダイアログは次のようになります。

［ツール］メニューから［C# run］を選択するか、または「**Alt-T Alt-R」**と入力すると、起動中の IDE ソース ファイルがコンパイルされます。コンパイルに成功すると、C# 実行可能ファイルが起動し、アウトプット ウィンドウに出力が表示されます。コンパイルに失敗すると、同じアウトプット ウィンドウにコンパイラの診断結果が表示されます。その場合、診断結果は Visual C++ version 6.0 と同じ様式であるため、F4 操作で診断結果を逐次検証できます。

制限事項：

  • この例は一番手前のソース ファイルのみをコンパイルし、リンクします。コンセプトの実証が目的であり、堅牢さや規模拡張性の証明が目的ではありません。実際には、皆さんはメークファイルを作成したり、nmake などのビルドツールを実行したりすることになるでしょう。

  • IDE から直接 C# をデバッグすることはできません。SDK デバッガを使う必要があります。いずれかの SDK デバッガを使える状態で起動する IDE カスタム ツールを作成する方法については、皆さんへの練習問題とします。

  • IDE のエディタは C# を知らないため、適切なテキストの書式設定や構文の色付けができません。C++ ファイルと同じ拡張子を C# ファイルに付けることで、この欠点はある程度解決できます。

  • Visual Studio version 6.0 のヘルプ システムは C# を知らないため、文脈依存ヘルプは正しく動作しません。

頻繁に議論される話題

私は MSDN の .NET に関連したコラムや記事に対する皆さんのコメントを丹念に読みました。また、Microsoft 以外の Web サイトやニューズグループに掲載された関連の話題も読みました。それらの話題を読み進むうちに、私は頻繁に見られる苦情や誤解、またそこから飛び火した熱のこもった議論や激しい論争に出会いました。そこで、私はそれらの話題のいくつかにコメントしたいと思います。

  • C# にはジェネリックスやテンプレートが存在しない。これらは多くの皆さんがほしいと思っているものです。私たちもほしいと思っています。現在、C# の設計チームが英国の Microsoft Research と協力し、ジェネリックスを言語に組み込む作業を進めています。この作業の成果の一部（少なくとも実験的な）が数か月内に発表されます。ただし、それは私たちの最初の標準的な C# リリースの一部というわけではありません。

  • 顧客の中には SDK に飽きたらず、完全な Visual Studio .NET 環境のダウンロード版を望んでいる方がいます。新しい Visual Studio がリリースされれば大反響間違いありません。しかし現時点では、コンパイラや他のツールに比べるとやや安定性に難がありなます。実際、私も前述したように C# で作業するために Visual Studio 6.0 セットアップを使って、安定性を確保し、機能を犠牲にしています。 私は最初のベータ版がリリースされたら Visual Studio .NET を使おうと思っています。何しろ、皆さんもほとんどの方がお使いになるでしょうから。

  • .NET Runtime にはガベージ コレクタが組み込まれています。ソース言語の出所に関係なく、ガベージ コレクタがすべての管理オブジェクトを制御します。必然的に、管理データを要求するすべての .NET 言語（C# を含む）がランタイムのガベージ コレクタに従うことになります。つまり、ガベージ コレクタは C# 自体の機能というよりも、C# が使用し、提示する（指定できる）ランタイムの機能となります。

  • ガベージ コレクションの結果として、C# のオブジェクトには確定的デストラクタが備わっていません。これは C# を使用する Java のプログラマには余り問題ではありませんが、C++ のプログラマには重大な問題です。たとえ C# のオブジェクトが C++ スタイルのデストラクタを許容しても、これらのオブジェクトは共通のランタイムの中で他の言語と相互に運用するのが難しくなります。

    皆さんの多くがこの機能を望んでいることは私たちも承知しており、私たちもさまざまな可能性を検討しています。これを実現するためには、言語とランタイムの両方を大幅に変更する必要があります。しかし、たとえ変更を行ったとしても（あくまでもたとえばの話ですが）、C++ の動作を完全に複製できるかどうかは甚だ疑問です。

  • .NET Runtime は従来の意味での仮想マシン (VM) ではありません。IL を実行する疑似 CPU がありません。代わりに、IL はネイティブ コードに翻訳されます。実際にプログラムを実行するのはネイティブ コードです。前のコラムでも述べたように、IL からネイティブへの翻訳はプログラムのインストール段階かプログラムの実行段階で行われます。

  • 本来、「C シャープ」という名前は、私のコラムのバナー グラフィックに示すような綴りになります。つまり、大文字の C のあとに音楽のシャープ記号が付きます。この記号は ASCII にはないため、通常、私たちは「C#」で代用しています。このため、「C ハッシュ記号」、「C ポンド記号」、果ては「C オクトソープ記号」など不正確な活字で代用されることがあります。私は個人的には聡明さと正確さを兼ね備えた「D フラット記号」が好きです。しかしこれも ASCII 以外の活字が必要にはなります。

参考情報

  • .NET SDK の PDC プレビュー リリース版のほかにも、PDC のスライド (http://commnet.pdc.mscorpevents.com/) やストリーム ビデオ (https://msdn.microsoft.com/events/pdc/tech/webcast.asp なども Web サイトからダウンロードできます。これらのうち、私は特に C# に関しては初級者向けの (http://commnet.pdc.mscorpevents.com/slides/5-313.ppt)、上級者向けの (http://commnet.pdc.mscorpevents.com/slides/5-422.ppt) をお勧めします。また .NET Framework のプレビュー版は (http://commnet.pdc.mscorpevents.com/slides/3-313.ppt)、言語の統合は (http://commnet.pdc.mscorpevents.com/slides/3-314.ppt) をお勧めします。

  • 私たちは C# 専門のニューズグループ () を含む .NET に関する公開ニューズグループ () を設立しました。また Microsoft の Web サイト上にグループ リスト (https://msdn.microsoft.com/net/#newsgroups) を掲載しています。

  • DevX も C# 専門のニューズグループ (news://news.devx.com/csharp.general) を含む独自の .NET ニューズグループ（news://news.devx.com/）を設立しました。DevX はこれらのグループの議論の場として Web 上に掲示板 (http://news.devx.com/) を設けています。この DevX のグループはかなり活発に活動しており、Microsoft も積極的に書き込みを行っています。

  • また DevX は Visual Studio .NET リソースの総合的なリスト (http://www.devx.com/free/press/2000/vsresources.asp) を掲載しているほか、新規ポータルを立ち上げました。

  • DevelopMentor は、.NET のメーリング リスト（http://discuss.develop.com/dotnet.html) を掲載しています。現在、加入者はおよそ 1,500 名、私もリストに加入しています。書き込みに対する反応は極めて活発です。DevX のニューズグループの中では、Microsoft が DevelopMentor のリストに相当数の書き込みを行っていますので、強くお勧めします。(DevX は、いわば FAQ としてメーリング リストのハイライトのアーカイブ（http://www.devx.com/free/press/2000/vs-qalist.asp）を掲載しています。

  • O'Reilly のエディタ John Osborn による C# のチーフ アーキテクト Anders Hejlsberg へのインタビュー（http://windows.oreilly.com/news/hejlsberg_0800.html）は非常に示唆に富んでいます。

まとめ

私はこの数か月間、少しずつ C# を研究していました。また私は先月、PDC の場で C# への転向に踏み切りました。読者の中にはこの 2 つのできごとが明らかに矛盾すると思われる方もいるでしょう。

PDC に出席するまで、私の C# に対する見方は比較的具体性に欠け、ランタイムのコンテキストが見えず全体像を把握できていませんでした。実際、私たちが C# を発表したときには、皆さんの多くがその不備を指摘したように、言語のリファレンスに実行環境の具体的な言及はありませんでした。

しかし私は PDC の場で、始めてそのコンテキストを知ることとなりました。さらに、私はそのコンテキストが共通のプログラミング モデルと実行環境内で多数の言語（C# だけでなく）を統合できることを知りしまた。同時に C# と .NET の全体像が見えたのです。そのとき、私は C# への転向に踏み切りました。その時の体験は大変に切実なものであり、皆さんも実際にその場に居合わせたならば、きっと私と同じように転向に踏み切っただろうと思います。

たとえ全員ではないにしろ、皆さんの多くは、私たち社員が客観性を失い、魂を売り渡したと考え、Microsoft には大したことができない、あるいは正しいことができないと思っているようです。そのように考えているとしたら、ここで読むのをやめたほうがよいかもしれません。私がどのようなメッセージをもたらそうとも、皆さんはメッセンジャーである私に対して猜疑心を持ち続けると考えられるからです。

また、皆さんの中のかなりの方が私たちが言うことを神の言葉のように受け取り、Microsoft が間違ったことを行うはずがないと思っていることも承知しています。そのような方も、ここで読むのをやめたほうがよいかもしれません。私が従来の Microsoft の方針に反する助言を行うことに対して明らかな矛盾を感じるかもしれないからです。

しかし、それ以外の読者は、今後も、毎月このコラムをお読みになることを期待しています。ようやく C# を現実に使える日がやってきたのです。そこで私は、特に標準 C++ とそのランタイムに関係のある C# とそのランタイムの話題について書いていきたいと思っています。

Robert Schmidt は MSDN のテクニカル ライターです。このほかに彼が寄稿している雑誌に、C/C++ Users Journal があります。そこでは、彼は編集補助およびコラムニストとして活躍しています。これまでのキャリアで、ラジオ DJ、野生生物飼育係、天文学者、ビリヤード場管理者、探偵、新聞配達夫、そして大学講師を経験しています。