スペイン語の翻訳 も利用可能です。（古いものですが）

基本事項

Question 1: Monoとはずばり何ですか?

Monoプロジェクトは、Ximianがスポンサーとなって、オープンソースでMicrosoftの.NET開発プラットフォームのUnixバージョンを開発している、オープンな開発環境のイニシアティブです。その目的は、Unix開発者がクロス プラットフォームの .NET アプリケーションを設計し配備することを可能にすることです。このプロジェクトは、Microsoftによって開発され今やECMAに標準として提出されている、さまざまな技術を実装することになるでしょう。

Monoプロジェクトでは、C#ベースの数多くのコンポーネント、ライブラリ、フレームワークの開発も巻き起こしてきました。今日では、Monoは.NET Frameworkの実装だけに限らず、その他のコンポーネントも包含してきています。MonoプラットフォームのコンポーネントのいくつかはMonoチームによって開発されたものですし、他のいくつかはわれわれが他のオープンソースの成果を取り込んできたものです。重要なものとしては:

• Remoting.CORBA: Mono用のCORBA実装です。

• Ginzu: ICE スタックのリモーティングに基づく実装

• Gtk#: UnixおよびWindowsシステム用のポピュラーなGUI ツールキットGtk+のバインディング。その他のバインディングも利用可能です: Diacanvas-SharpやMrProject

• #ZipLib: （Zipやtarの）さまざまな種類の圧縮ファイルやアーカイブを操作するライブラリ

• GlGen (Mono CVSから利用可能): OpenGLのバインディング

• Mono.LDAP: .NET アプリのLDAPアクセス

• Mono.Data: われわれはPostgres, MySql, Sybase, DB2, SqLite Tds (SQL server プロトコル）, Oracleデータベースのサポートを出荷しています

• Mono.Cairo: Cairo レンダリングエンジンのバインディング（われわれのSystem.Drawingはこの上に実装されています）

• Mono.Posix: C#を使用してPOSIXアプリケーションを構築するためのバインディング

• Mono.Http: あなたのアプリケーションでカスタムの、埋め込みHTTPサーバや共通のHTTPハンドラの作成をサポートします

Question 2: Monoと.NETイニシアティブの違いは何ですか？

「.NET イニシアティブ」というのは、Microsoftの漠然とした、 企業全体の取り組みであり、その一つの部分が、 クロスプラットフォーム開発フレームワークである、ということです。 Monoは開発フレームワークの実装であり、Passportや、サービスとしての ソフトウェア[software-as-a-service]や企業の再ブランド化といった、 .NETイニシアティブの他の関連項目を実装したものではありません。

Question 3: どんな技術がMonoには含まれているんでしょう？

Monoは新しいソフトウェアを設計するために便利なコンポーネントを数多く含んでいます:

• クラスローダー、ジャストインタイム コンパイラ、 ガベージ コレクションのランタイムを含む、 コモン ランゲージ インフラストラクチャ (CLI) 仮想マシン。

• CLR上で、あらゆる言語で動作するクラスライブラリ。

• C#言語のコンパイラ。将来的に、われわれは コモン ランゲージ ランタイムを対象にする、 他のコンパイラにも着手するかもしれません。

Windows は、Managed C++, Java Script, Eiffel, Component Pascal, APL, Cobol, Perl, Python, Scheme, Smalltalk, Standard ML, Haskell, Mercury, Oberon といった 数多くの言語による仮想マシンを対象とするコンパイラをもっています。

CLRとコモン タイプ システム (CTS) は、アプリケーションとライブラリを、そのバイトコードを対象とする、別々の言語の集合体で書けるようにしています。

これは、たとえばもしあなたがC#で代数的な操作を行うクラスを定義したら、そのクラスはCLIをサポートしている他のあらゆる言語から再利用できるということです。あなたはあるクラスをC#で作成し、C++でサブクラス化し、Eiffelのプログラムでインスタンス化することができることでしょう。

単一のオブジェクトシステム、スレッディングシステム、クラスライブラリ、ガベージコレクションシステムが、それらの言語全ての間で共有できるのです。

[訳注 - 実際にはそんな単純ではないということが指摘されている{atmarkit.co.jp}。]

Question 4: どこでこれらの技術の仕様を見つけることが出来るでしょう？

こちらから見ることが出来ます:

C# http://www.ecma.ch/ecma1/STAND/ecma-334.htm

CLI http://www.ecma.ch/ecma1/STAND/ecma-335.htm

Question 5: あなたたちは .NET Framework SDKのクラスライブラリを実装するんですか？

はい。われわれは .NET Framework SDK クラスライブラリのAPIを実装するつもりです。

Question 6: あなたたちは ECMA互換のクラスライブラリセットを提供するんですか？

いずれそうなるでしょう。われわれの現在の焦点はMicrosoftのSDKと相互運用することにありますが、ECMA互換のライブラリセットも提供することでしょう。

Question 7: "Mono" という名前の意味するところは何ですか？

Monoはスペイン語で「サル」を表す単語です。われわれはサルが好きなんですよ。

そういえばBonoboもサルの一種だ。

Question 8: Mono は利用可能(usable)ですか?

JITエンジンはIntel x86マシンで利用可能です。 他の非Intel x86マシンではインタープリタが利用できます。

クラスライブラリは、いくつかの現存するアプリケーションを実行させるのに、 十分なくらい成熟しています（たとえばコンパイラがそうですし、 日々どんどんアプリケーションがMonoでネイティブに開発されています）。

Question 9: いつ出荷するつもりですか？

リリース プランの詳細についてはMono ロードマップ を見てください。

Question 10: Monoに含める予定の主要なコンポーネントには、どんなものがありますか？

願わくば、Microsoftがそのフレームワークで出荷しているもの全て （ADO.NETやASP.NETとか）です。 それと、われわれは、サードパーティの開発者が、MonoでもWindows でも動作するような、再利用可能コンポーネントを作成することを支援します。

Question 11: どうすれば私も力になれますか？

協力 のセクションをチェックしてください。

Question 12: あんたたちは他の誰かの成果をコピーするだけで済ませているんじゃないの？

私たちは、自由なオペレーティングシステムのためにアプリケーションを開発するための、ベストなツールを、プログラマーに提供することに関心がありますし、 そのようなシステムが、他のスタンダードと適合するような相互運用性を実現する、助けになりたいのです。

これ以上の背景については、Mono Projectのホワイトペーパーの、the project を読んでください。

Question 13: Miguel はかつて、MonoはCOBOLで実装されている、って言ってたけど、本当ですか？

いや、そいつはジョークですって。

MonoプロジェクトにおけるNovellの役割

Question 14: なぜNovellは.NETの仕事をしているんですか？

Novellは自由なオペレーティングシステムのためのアプリケーションを開発する、ベストツールをプログラマーに提供することに関心があります。

詳しくは、このプロジェクトの存在意義のページを読んで下さい。

Question 15: Novellはこんな規模のプロジェクトを引き受けられるのでしょうか？

もちろんダメでしょう。NovellはMonoプロジェクトのサポーターですが、このいくばくかの実装をつくる唯一の方法は、完全な、自由なソフトウェアのコミュニティに参加してもらうことです。 助力していただけるのでしたら、協力のページに来て下さい。

Question 16: Novellはどの部分で作業するでしょう？

われわれはその労働リソースのほとんどを、開発と実行の環境をリリースするためのクリティカル パス[訳注: ここで遅れたら全てが遅れる、という部分]上の部分に捧げます。このプロジェクトが現実世界で利用可能な段階に至ったら、開発者が先に進めるためのクリティカルマス[必要不可欠な部分]を達成することになるでしょう。

Question 17: NovellはMonoを商用で提供するつもりですか？

Monoが出荷できる準備が出来たら、NovellはMonoの商用サポートやサービスを提供するつもりです。Monoコンポーネントも商用ライセンスで利用可能になります。ライセンスの詳細については、mono-licensing@ximian.comに連絡してください。

Question 18: Novell はMonoまわりのコンサルティングサービスを提供しますか？

ええ、NovellはMono周辺のコンサルティングサービスを提供して、あなたのニーズに最適なものにします。ランタイムエンジンを移植し、カスタマイズし、個別のクラスの作業をし、個別のニーズに合わせてコードをチューニングします。

Question 19: あなたたちはMonoが完了するときまで待てるんですか？

Monoはその成熟度に応じて、多様な段階で出荷します。人によっては、最初に出荷されるであろう、この技術のサブセットだけを必要とするでしょう。詳しくはMono ロードマップを見てください。

Mono と GNOME

Question 20: Mono は GNOME とどのように関係していますか？

いろいろな点でです。このプロジェクトは GNOME コミュニティのために、発展したツールを提供するというニーズから誕生したもので、利用可能であれば、GNOMEで開発された既存のコンポーネントを使うことになるでしょう。たとえば、われわれはGtk+とLibartを柄ってWinformsとDrawing2D APIを実装する計画を立てていますし、GObjectをサポートすることも考えています。

Question 21: GNOME ファウンデーションや GNOME チームが Mono を採用したんですか？

Monoはこれらのグループに採用されるにはまだ新しすぎます。われわれは、自分たちが提供するこのツールが、GNOMEファウンデーションのメンバーを含む自由なソフトウェアのプログラマーに、そしてGNOMEプロジェクト全般に採用されることを望んではいます。

Question 22: GNOMEプログラマーは今からMonoに切り替えるべきなんでしょうか？

まだ「切り替える」ことを議論するのは早すぎるでしょう。Monoのどの部分も、6ヶ月以内には出荷できる状態にならないでしょうし、完全な実装は、大まかに言って1年以上先になるでしょう。

われわれは、GNOME開発者が既存のツール、ライブラリ、コンポーネントを使って継続することをお勧めします。GNOMEによってなされた発展は、さまざまなクラスの「バックエンド」として、Monoに影響することでしょう。

Question 23: MonoはBonoboコンポーネントとの互換性を含みますか？ MonoとBonoboの間の関係は何ですか？

ええ、われわれはBonoboコンポーネントをMono内部で実装し使用するためのクラスのセットを提供する予定です。MonoはBonoboコンポーネントをもっと簡単に書けるようにすべきです。Windows上の.NETが.NETコンポーネントをCOMにエクスポート出来るのと同じように。

Question 24: MonoはGNOMEに依存しますか?

いいえ。MonoはGNOMEに依存しません。われわれはGNOMEチームによってプロデュースされた'glib'ライブラリみたいな少数のパッケージを使っています。

Question 25: でも、それではわたしはGNOMEアプリケーションを設計することが出来るんでしょうか？

ええ、われわれは、皆さんがMonoを使ってGNOMEアプリケーションを書けるようにするでしょう。

Question 26: GNOMEのC#バインディングはありますか？

Yes, the Gtk# project provides bindings for Gtk+, Gdk, Atk, libgnome, libgnomecanvas, and libgnomeui. Other libraries under the GNOME framework will be added on an as-needed (and as-requested) basis.

GUI アプリケーション

Question 27: MonoでGUIアプリケーションが作れるようになりますか？

はい、あなたはGUIアプリケーションが設計できるようになるでしょう。実際、それがわれわれの主な焦点です。今日では、あなたはGTK#または#WTを使って、GUIアプリケーションを開発することができますし、Windows.Formsのサポートも進行中です。

Question 28: Gtk# と System.Windows.Formsの違いは何ですか？

Gtk# は Gtk+ツールキットのC#（およびその他のCILが有効な言語）のバインディング セットです。System.Windows.Forms は Microsoftによって定義された、GUIアプリケーション設計用のAPIです。

Question 29: What are you using to implement Windows.Forms?

Windows.Forms is currently being implemented on top of a modified version of Wine that can be used as a library: WineLib.

Essentially Wine is used as a library that happens to implement the "Win32" toolkit and our Windows.Forms becomes a managed layer on top of this toolkit.

There are several advantages in this approach: we get Wndproc message compatibility for free (Wndproc is an overridable method in the Control class and it is used to perform advanced tricks with the GUI toolkit) as well as allowing third-party controls that are used to P/Invoke into Win32 in the Windows world to work out of the box on Linux/MacOS.

Question 30: Why not implement System.Windows.Forms on top of Gtk# or Qt#?

Compatibility.

Although it is possible to run simple Windows.Forms applications with the Gtk#-based backend of Windows.Forms, it is very unlikely that the implementation will ever implement everything needed for full compatibility with Windows.Forms.

The reason is that Windows.Forms is not a complete toolkit, and to work around this problem some of the underlying Win32 foundation is exposed to the programmer in the form of exposing the Windows message handler (WndProc). Any control can override this method. Also developers often P/Invoke into Win32 to get to functionality that was not wrapped.

To achieve full compatibility, we would have to emulate this, and it would take too long.

For more details see the winforms page

Question 31: Wine applications do not look like native applications, what are you going to do about this?

We have already a few patches into our version of Windows.Forms that makes Wine use the colors and font settings from your desktop, improving the integration a lot. In the future, we will continue to improve this interoperability scenario.

Question 32: powered by Mono なシステムでスマートなクライアントを実行させられるようになりますかね？

あなたのアプリケーションが100% .NETであり、P/InvokeでWin32関数を使用していないのであれば、あなたのスマートなクライアントアプリケーションはMonoプラットフォームで実行できることでしょう。

Question 33: Gtk#について、どこでより詳しく勉強できますか？

以下のリンク が、あなたをこのプロジェクトのページに送り出してくれますよ。

Question 34: Gtk#で何が出来ますか？

Gtk# はとても便利になりつつありますし、あなたはアプリケーションやGNOMEデスクトップ環境で見られるようなアプレットを作ることができます。これは簡単にインストールできますし、やってみる価値はありますよ。

Question 35: Gtk#を使ったわたしのHelloWorld.csをコンパイルするにはどうすればいいんでしょう？

これで試してみてください: mcs -r:gtk-sharp HelloWorld.cs

Question 36: 何かしらのGTK#コントロールにDataAdapterを結びつける方法はありますか？

`DbClient'というサンプルが gtk-sharp/samples の中にあるのを見ていただけます。これは、Postgresデータベース上の情報を追加・更新・削除する、Gtk#のサンプルプログラムです。われわれがテーブル/ツリーのウィジェットを作ったら、誰かがSystem.Dataへのアダプタを書いてくれると確信しています（ツリー/リストのウィジェットはビュー/モデルを使って書かれていますので、あなたはモデルをデータベースにマッピングすることだけを必要とします）。 gtk-sharp/sample/DbClientを見てもらうことが出来れば、そこにはSystem.Dataを使うGtk#アプリケーションがあります。これはDataAdapterは使っていませんが、DataReaderを使っています。

Question 37: Windows.Formsがいつリリースされるか、見通しは立っていますか？

現在の計画では、2004年第4四半期を狙っています。

Question 38: Do you have a comparission chart about the various toolkit offerings?

A document explaining this is available at: http://primates.ximian.com/~miguel/toolkits.html.

Mono と Microsoft

Question 39: Microsoft はこのプロジェクトについて Ximian を助けているのですか？

現時点では、XimianとMicrosoftの間で、大してレベルの高いコミュニケーションがとられているわけではありませんが、.NETやECMAグループで作業しているエンジニアとは非常に親しく、私たちの質問に非常に良い回答をしてくれたり、私たちに仕様の一部を明確にしてくれています。

Microsoftは.NETの他の実装に関心があり、その目的で、喜んでECMA仕様をより正確にする努力を払います。

Ximian も ECMAのC#とCLIの委員会ミーティングに参加要請されています。

Question 40: Microsoft や Corel はこれを実行するために Ximian に金銭を支出していますか？

いいえ。

Question 41: Microsoftが仕様を変更してMonoを使い物にならなくすることを恐れることはありませんか？

いいえ。MicrosoftはCLIやC#言語を、多くの言語と協調できるような強力な基盤を作成できるものであることを立証しました。われわれはそれを常に心に留めています。

たとえプラットフォームの変更が、文書化されることなく行われたとしても、既存のプラットフォームにはそれ自身の価値があるでしょう。

Question 42: あなたたちはMonoをECMA仕様に基づいて書いているんですか？

ええ、われわれはECMA仕様と、.NETについて出版された既刊のマテリアルに基づいて書いています。

Question 43: もしわたしのアプリケーションがMonoを使ったら、わたしはサービス料金を払わないといけませんか？

いいえ。MonoはMicrosoftのイニシアティブである、サービスとしてのソフトウェア[software-as-a-service]とは関係ありません。

Question 44: MonoプロジェクトはMicrosoftのHailstormの取り組みと関係がありますか？ XimianはHailstormを支持しているんですか？

いいえ。MonoプロジェクトはMicrosoft .NET 開発プラットフォームのツールとの互換のセットを提供することに焦点を当てています。 Windows XPやその他のサービスの一部となっている、MS PassportベースのHailstormのシングルサインオンのシステムについて、言及も要求も支持もするものではありません。

Question 45: Monoや.NETアプリケーションはMicrosoft Passportに依存しますか？

いいえ。MS PassportはMonoツールで作成された.NET互換のアプリケーションを実行することには、何の関係もありません。あなたが必要とするのは、ジャストインタイムコンパイラ(JIT)だけです。

Question 46: もしMicrosoft が「シェアードソース」ライセンスのもとで彼らの.NETプラットフォームをリリースしたら、わたしは他のものに迷う必要があるんでしょうか？

シェアードソースの実装は高くつくでしょうし、その利用は、特に商用の場合は厳密に制限されるものでしょう。われわれは、重要な権利の多くを受領者に許諾するような実装に向けて作業しているのです: あらゆる目的での利用、再頒布、改変、改変物の再頒布などを。

これは、われわれが自由なソフトウェアと読んでいるものです。

Question 47: Mono は Passport のフリー実装ですか？

いいえ。Monoは単なるランタイム、コンパイラ、クラスライブラリのセットです。[訳注 - そういうのは、どちらかといえばDotGNUの目的です]

Question 48: System.Web.Security.PassportIdentity クラスは わたしのソフトウェアがPassportに依存することを意味するのでは？ いいえ。アプリケーションは Passportサイトに接続するAPIを使っても良いですが、そのようにする必要は別にありません。

あなたのアプリケーションがPassportを使わない限り、あなたはPassportを必要としません。

Question 49: Linux上で動作するMonoは、Linux上でPassportを利用可能にするでしょうか？

いいえ。しかし、LinuxベースのWebサーバ用のPassportツールキットなら、Microsoftから利用可能になっています。

Question 50: MonoはMicrosft OfficeをLinux上で実行させてくれるんでしょうか？

いいえ。そうはならないでしょう。Microsoft Office は Windowsアプリケーションです。 WindowsアプリケーションをIntel Unixシステム上で実行する方法について詳しく知りたければ、Wineプロジェクトを参照してください。

Question 51: MonoはWebMatrixを実行できますか？

いいえ。あれはまだ現在実装されていないSystem.Windows.Formsサポートを必要とします。

Question 52: MonoはPassportみたいなものを持っていますか？ MonoはXSP用の、サーバサイドのPassportやその類似品のクライアントクラスをもっていますか？

まだです。しかし、認証用のクライアントサイドAPIは問題ではありません。われわれは、たとえばLiberty Aliance APIなど、他の認証APIをたくさん持つことになるでしょう。問題は、Webプロバイダを利用している人たちが、これを認証に使おうとするかもしれないということです。[訳注 - ちなみに、オープンソースのLiberty Alliance APIとして、SourceID.NETが存在する。]

Mono プラットフォーム

Question 53: Monoはどのオペレーティング システム上で動作しますか?

MonoはLinux, Unix, Windowsのシステム上で動作することが知られています。

Question 54: Can I run Mono applications without using `mono program.exe'?

Yes, this is possible on Linux systems, to do this, use something like:

if [ ! -e /proc/sys/fs/binfmt_misc/register ]; then
	/sbin/modprobe binfmt_misc
	mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
fi

if [ -e /proc/sys/fs/binfmt_misc/register ]; then
	echo ':CLR:M::MZ::/usr/bin/mono:' > /proc/sys/fs/binfmt_misc/register
else
	echo "No binfmt_misc support"
	exit 1
fi

Question 55: Monoは何のアーキテクチャをサポートするんですか?

Monoはx86ベースのシステムではジャストインタイム コンパイラを公開しています。 これはLinux, FreeBSD, Windows(XP/NTコア)で正しくテストされたものです。

s390, SPARC, PowerPCアーキテクチャ上で動作する、 より遅いインタープリタもあります。

Question 56: MonoはWindows 9xやME editionで動作しますか?

Monoが動作するには、UnicodeバージョンのWin32 APIを必要としますが、 Win9xでは *W 関数の一部だけがサポートされています。

Microsoft Layer for Unicodeという、これらのAPIを9xのシステムに提供する実装があります。

残念ながら、これは遅延ロードのために、ldではサポートされていない、 リンカーのトリックを使っています。ですので、何かしらのアダプタが必要です。 あなたは、Monoをリンクするために、MSLUと、以下のライブラリのいずれかを必要とすることでしょう。unicows.dll http://mono.eurosoft.od.ua/files/unimono.zipか、でなければネットで "libunicows" を探してください。

Monoのソースコードには何も変更が必要ありません。リンカーが、Win32 のライブラリの代わりに、アダプター ライブラリのインポートを解決することを、 確認するだけです。 これは、リンカーの指定ファイルで、-lkerner32/user32 より前に -lunimono を追加するだけです。

Question 57: Why support Windows, when you can run the real thing?

There are various reasons:

• About half the contributors to Mono are Windows developers. They have many different for contributing to the effort, and we find it very important to let those developers run the runtime on Windows without forcing them to use a new operating system.
• Supporting Windows helps us identify the portable portions of Mono from the non-portable versions of it, helping Mono become more portable in the future.

• Mono does not heavily modify the windows registry, update system DLLs, install DLLs to the Windows/System32 path. Another words, I knew Mono would not cause any legacy enterprise applications to stop working - and it hasn't. However, our CIO er is againt it because of the changes that would be made to Windows 2000, such as, affecting security.

Compatibility

Question 58: Can Mono run applications developed with the Microsoft.NET framework?

Yes, Mono can run applications developed with the Microsoft .NET Framework on Unix. There are a few caveats to keep in mind: Mono has not been completed yet, so a few API calls might be missing; And in some cases the Mono behavior *might* be incorrect.

Question 59: Will missing API entry points be implemented?

Yes, the goal of Mono is to implement precisely the .NET Framework API (as well as compile-time selectable subsets, for those interested in a lighter version of Mono).

Question 60: If the behavior of an API call is different, will you fix it?

Yes, we will. But we will need your assistance for this. If you find a bug in the Mono implementation, please fill a bug report in http://bugzilla.ximian.com. Do not assume we know about the problem, we might not, and using the bug tracking system helps us organize the development process.

Question 61: Can I develop my applications on Windows, and deploy on a supported Mono platform (like Linux)?

Yes, you can.

As of today, Mono is not 100% finished, so it is sometimes useful to compile the code with Mono, to find out if your application depends on unimplemented functionality.

Question 62: Will applications run out the box with Mono?

Sometimes they will. But sometimes a .NET application might invoke Win32 API calls, or assume certain patterns that are not correct for cross-platform applications.

Question 63: What is a 100% .NET application?

A `100% .NET application' is one that only uses the APIs defined under the System namespace and does not use P/Invoke. These applications would in theory run unmodified on Windows, Linux, HP-UX, Solaris, MacOS X and others.

Note that this requirement also holds for all assemblies used by the application. If one of them is Windows-specific, then the entire program is not a 100% .NET application.

Furthermore, a 100% .NET application must not contain non-standard data streams in the assembly. For example, Visual Studio .NET will insert a #- stream into assemblies built under the "Debug" target. This stream contains debugging information for use by Visual Studio .NET; however, this stream can not be interpreted by Mono (unless you're willing to donate support).

Thus, it is recommended that all Visual Studio .NET-compiled code be compiled under the Release target before it is executed under Mono.

Question 64: Can I execute my Visual Studio .NET program (Visual Basic .NET, Visual C#, Managed Extensions for C++, etc.) under Mono?

Yes, with some reservations.

The .NET program must either be a 100% .NET application, or (somehow) have all dependent assemblies available on all desired platforms. (How to do so is outside the bounds of this FAQ.)

Mono must also have an implementation for the .NET assemblies used. For example the System.EnterpriseServices namespace is part of .NET, but it has not been implemented in Mono. Thus, any applications using this namespace will not run under Mono.

With regards to languages, C# applications tend to be most portable.

Visual Basic .NET applications are portable, but Mono's Microsoft.VisualBasic.dll implementation is incomplete. It is recommended to either avoid using this assembly in your own code, only use the portions that Mono has implemented, or to help implement the missing features. Additionally, you can set 'Option Strict On', which eliminates the implicit calls to the unimplemented Microsoft.VisualBasic.CompilerServices.ObjectType class. (Thanks to Jﾃｶrg Rosenkranz.)

Managed Extensions for C++ is least likely to operate under Mono. Mono does not support mixed mode assemblies (that is, assemblies containing both managed and unmanaged code, which Managed C++ can produce). You need a fully-managed assembly to run under Mono, and getting the Visual C++ .NET compiler to generate such an executable can be difficult. You need to use only the .NET-framework assemblies, not the C libraries (you can't use printf(3) for example.), and you need to use the linker options /nodefaultlib /entry:main mscoree.lib in addition to the /clr compiler flag. You can still use certain compiler intrinsic functions (such as memcpy(3)) and the STL. You should also see Converting Managed Extensions for C++ Projects from Mixed Mode to Pure Intermediate Language at MSDN. Finally, you can use PEVERIFY.EXE from the .NET SDK to determine if the assembly is fully managed.

Thanks to Serge Chaban for the linker flags to use.

Mono と Portable.NET

Question 65: Mono と Portable.NETの違いは何ですか？

Monoの大部分はC#で書かれようとしています。Cで書かれる部分はごく僅か（JITエンジン、ランタイム、ガベージコレクションシステムへのインターフェース）です。

Mono固有の部分を説明するのは簡単です:

• 発展したネイティブコード コンパイル エンジン: ジャストインタイムコンパイル (JIT)も、CILバイトコードのネイティブコードへのプリコンパイルもサポートされています。

• コード最適化の基盤: Monoの新しいコードジェネレータは、最初のJITエンジンにおける経験に基づくもので、幅広く発展したコンパイラの最適化のトリックを実装することを可能にしています。SSAフレームワークによって、数多くの新しい最適化が可能になりました。

  The current list of optimizations are: Peephole postpass, Branch optimizations, Inline method calls, Constant folding, Constant propagation, Copy propagation, Dead code elimination, Linear scan global reg allocation, Conditional moves, Emit per-domain code, Instruction scheduling, Intrinsic method implementations, Tail recursion and tail calls, Loop related optimizations, Fast x86 FP compares, Leaf procedures optimizations

• C#で書かれたセルフホスティングのC#コンパイラ。これはクリーンで、メンテナンスし易いものです。

• Focus on the .NET Framework: we are tracking down the .NET Framework API definition, as we believe it is the API people will be most familiar with.

• マルチプラットフォームのランタイムエンジン: JITエンジンとインタープリタの両方が存在します。JITエンジンは現在のところ、x86システム、PowerPC、SPARCシステムで動作します。インタープリタはx86、SPARC、StrongARM、s390、PowerPCシステムで動作します。

  JITエンジンは、現時点でPowerPC、s390、SPARCおよびamd64システムに移植中です。

• 現時点で、Linux、BSD、MacOS、Windows、Solarisをサポートします。

• JITエンジンは、良いコードを生成するだけでなく、JITエンジンを他のシステムに再ターゲットするための基盤ともなるような、移植可能な命令セレクタを使って書かれています。

• ランタイムにおけるリモーティングを完全サポートしています。

• 2002年4月の時点で、C#コンパイラ、JITエンジン、クラスライブラリは、システム全体をセルフホスティングするにのに十分成熟しています。すなわち、われわれは現時点で、MonoをMono自身によって完全に開発することが出来ます。

  By forcing ourselves to use our own code to develop our tools, we bug fix problems rapidly, and the system is overall more robust and tested than if we did not.

• Our class libraries are licensed under the terms of the MIT X11 license which is a very liberal license as opposed to the GNU GPL with exceptions, this means that Mono can be used in places where the GPL with exceptions is not permissible.

• Mono has a complete Web Services stack: we implement ASP.NET web servers and web clients as well as implementing the Remoting-based SOAP infrastructure.

• Remoting implementation: Mono has a complete remoting infrastructure that is used in our own codebase to provide added functionality and performance to our ASP.NET engine and more.

• Mono has a complete C# 1.0 implementation and has been stress tested a lot more than Portable.NET's compiler.

• Mono's C# compiler has strong error handling and has closer adherence to the specification.

• Mono's C# compiler is written in C# which is easier for new developers to come in and improve, fix and tune. The Mono C# compiler in C# is faster than their C-based compiler.

• Preview of C# 2.0: a work in progress for a 2.0 implementation of our compiler is available (iterators, generics and anonymous methods are available in our "preview" compiler).

• Mono has a complete Reflection and Reflection.Emit: these are important for advanced applications, compilers and dynamic code generation.

• Mono has a complete managed XML stack: XML, XPath, XML Serializer, XML Schema handling are fully functional, feature complete and tuned for performance.

• Mono has a complete cryptography stack: we have a complete crypto stack: we implement the 1.0 and 1.1 APIs as well as using our fully managed stack to implement the SSL/TLS transports.

• Extensive database support: Mono ships with database provides for Firebird, IBM DB2, Oracle, Sybase, Microsoft SQL Server, SQL Lite, MySQL, PostgresSQL, Ole DB and ODBC.

• Mono includes full LDAP support.

• われわれには、Monoがこれ無くしてあり得ないような、開発者の大きなコミュニティがあります。

In general, Mono is more mature and complete since it has been used to develop itself, which is a big motivator for stability and correctness, while Portable.NET remains pretty much an untested platform.

Question 66: I hear Mono keeps changing the P/Invoke API, why?

We are just fixing our implementation to be compatible with the Microsoft implementation. In other words, the Mono P/Invoke API is more complete when compared to the Portable.NET version, hence various pieces of software that depend on this extended functionality fail to work properly with Portable.NET.

Webサービス

Question 67: MonoはWebサービスとはどのように関係していますか？

Monoは、Webサービスの設計プロセスを単純化・効率化するために、.NET Frameworkが実装したものと同一のクラスのセットを実装するであろうという点でのみ、Webサービスと関連します。

しかし最も重要なのは、Monoがオープンソースの.NET Framework実装だということです。

Question 68: MonoでWebサービスを作ることができますか？

Monoで実行できる.NETのWebサービスを書くことができるようになるでしょう。逆もまた真なり、です。

Question 69: もしMonoがSDKクラスを実装したら、.NET Webサービスをそれで書いて実行することができますか？ はい。プロジェクトが完了したら、あなたはWindowsの.NET Framework SDKを使ってWebサービスを書くのと同じ技術を使うことが出来るようになるでしょう。

Question 70: Soupは？ MonoなしでSoupを使うことはできますか？

Soup はSOAPサーバとSOAPクライアントを作るためのGNOMEアプリケーション用のライブラリであり、Monoが無くても使えます。あなたはsoupのソースコードを、GNOMEのBonsaiを使ってブラウズできます。

Question 71: CORBAを使うことができますか？

はい。CLIには（CORBAのような）RPCシステムに本当に簡単に公開できる、十分なクラスの情報を含んでおり、オブジェクトによるサポートを必要とすることもありません。

Remoting.CORBA is a CORBA implementation that is gaining momentum.

Building an implementation of the Bonobo interfaces once this is ready should be relatively simple.

Question 72: わたしのオブジェクトをXML以外のものでシリアライズすることはできますか？

はい。シリアライズのツールはまだ計画されていませんし、ご自分で実装しなければならないでしょうけれども。[訳注 - これは少しばかり内容が古い。Runtime SerializationはLluis Sanchezの作業の成果として、既にサポートされている]

Question 73: Will Mono use ORBit?

There are a few advantages in using ORBit, like reusing existing code and leveraging all the work done on it. Michael Meeks has posted a few reasons, as well as some ideas that could be used to reuse ORBit.

Most users are likely to choose a native .NET solution, like Remoting.CORBA

MonoDoc

Question 74: MonoDocとは何ですか?

MonoDoc はグラフィカルなドキュメントのエディタおよびビューアです。今のところ、MonoDocはGtk#アプリケーションとして構成されており、ヘヴィな開発状況にあります。

開発ツールと問題点

Question 75: I am having trouble compiling a new version of Mono from CVS, it complains about my runtime being out of sync.

To upgrade your class libraries and compiler, see the INSTALL.txt in the MCS directory.

The single biggest source of confusion seems to be the "Your runtime is out of sync" messages. Realize that this is *normal* while BUILDING. Think about it: you're building a new class library with the old runtime. If the new class library references a function that the old runtime knows nothing about, the runtime system issues this warning.

Basically what needs to happen is for a new mono runtime to be compiled, then the corlib class library be compiled, and once this is done, install the new runtime, followed by corlib.

Once this is done, you can continue building your entire environment.

For instance you just need to: 1.- Upgrade your Mono runtime (you might better do it with the mono-build.sh script available in the download page. 2.- Get the latest mono-lite tarball from the daily snapshots page, unzip and untar and copy all the dll files to your install path lib directory (typically pointed by the $MONO_PATH variable). Copy all the exe files to the install path bin directory. 3.- Then checkout or update your mcs CVS copy. Then follow the steps described in mcs/INSTALL.txt.

Question 76: CLI機能をバイトコードやJITなしで使うことは可能ですか？

はい。CLIエンジンは共有ライブラリとして利用可能になるでしょう。 ガベージコレクションエンジン、スレッディング アブストラクション、オブジェクトシステム、動的タイプコードシステム、もしC開発者が望むなら、このJITは、彼らのアプリケーションで開発するために使うことも可能でしょう。

Question 77: 新しい開発ツールを作るつもりは？

運が良ければ、自由なソフトウェアの熱烈な支持者が、開発環境を改善してくれるツールを貢献してくれることでしょう。それらのツールは最初はMicrosoftのCLI実装を使って開発され、後からMonoで実行される、ということも可能です。

We are recommending people to use and contribute to existing projects like SharpDevelop, Anjuta and Eclipse.

Question 78: どのようなルールが、共通中間言語(CIL)をJITerにとって便利な形にしてくれるのでしょうか？

主要なルールは、CLIにあるスタックが一般用途のスタックでないということです。あなたはこれを、値の計算、関数への引数渡し、あるいは値の返却以外の目的で使うことはできません。

いかなる呼び出しまたは戻り命令でも、スタック上にある型は、あなたのコードの実行のフローから、同じように独立していなければなりません。

Question 79: CILがJIT処理の理想であり、インタープリタにとっては効率的でないというのは本当ですか？

CILはJVMバイトコードよりは良くJIT処理されますが、あなたがJVMバイトコードにインタープリットすることができるのと同じくらいしか、簡単にそれらをインタープリットできません。

Question 80: MonoでASP.NETをサポートするのに"XSP"っていう名前はちょっと紛らわしくないですか？（Apacheプロジェクトにあるものと同じですよね）

Monoでは、xspはASP.NETページのC#コードジェネレータの名前にすぎません。Apacheプロジェクトでは、これは「拡張可能なサーバページ」技術を表す言葉であり、全然違うものですから、競合するものではないです。

Question 81: Monoのためにaspxサーバを開発する計画はありますか？

XSP 参照実装サーバが利用可能ですし、Apacheと一緒にmod_monoを使用することも出来ます。

Question 82: Linuxでクラスライブラリを開発することができる箇所が、もうありますか？

はい。Monoは2002年5月からセルフホスティングしています。

Question 83: monoの動作確認済みのコピーを /usr の中にインストールして、実験的なコピーを他の場所に置いて、両方のコピーがそれぞれのライブラリを使うようにすることができますか？（私、Linuxのライブラリパスをまだよく知らないんです）

ええ。単純に、インストール時プレフィックスを2つ使ってください。

Question 84: テストやテストスイートはどうやって書くべきでしょうか？

もしあなたがC#のテストスイートを行うなら、それをMono C#コンパイラから独立して保持してください。そうすれば他のコンパイラ実装が、後で使うことができますから。[訳注 - genericサポートを追加したgmcsのようなものを想定していただきたい]

Question 85: mscorlibとして署名されている他のcorlibを持つのって恐すぎません？

われわれはPEファイルを保存するときにも、corlibをmscorlibにリネームします。実際、ランタイムはmonoで生成されたプログラムをちゃんと実行できます。

Question 86: 伝統的な .c -> .o -> .so という流れみたいな、最終的なモジュールでリンクさせることができるように、C#ファイルをビルドして何らかの中間フォーマットの形にすることができますか？ できます: mcs /target:module file1.cs, mcs /target:module file2.cs, mcs /target:exe file1.dll file2.dll /out:mybin.exe

Question 87: 近い将来に、リモーティングを実装する計画が何かありますか？

The remoting infrastructure is in place. We have implementations of the TcpChannel, HttpChannel and the Soap and Binary Formatters. They are compatible with .NET.

However, some classes from the library may have a different binary representation, because they may have a different internal data structure, so for example you won't be able to exchange a Hastable object between Mono and MS.NET. It should not be a problem if you are using primitive types, arrays or your own classes. In any case, could you post a test case?

Question 88: わたしのCのコードは、Linux上で使うことができない __stdcall を使っています。 どうやったら、このコードをWindows/Unixのプラットフォーム互換にすることができますか?

その__stdcall属性を STDCALL マクロで置き換えて、新しいgccバージョン用に、 あなたのCのコードに以下を含めてください:

#ifndef STDCALL #define STDCALL __attribute__((stdcall)) #endif

Question 89: I want to be able to execute Mono binaries, without having to use the "mono" command. How can I do this?

From Carlos Perellﾃｳ:

I think that the best solution is the binfmt feature with the wrapper that exists with Debian packages at:

http://www.debianplanet.org/mono/dists/unstable/main/source/admin/

If you want use it with Big endian machines, you should apply a patch (http://carlos.pemas.net/debian/mono/binfmt-detector-cli.c.diff)

It works really good and lets you use wine also, it reads the .exe file headers and check if it's a .net executable.

This way you just execute: ./my-cool-mono-application.exe and it works without the need of any wrapper.

Question 90: I see funny characters when I run programs, what is the problem?

(From Peter Williams and Gonzalo Paniagua):

This is Red Hat 9 (probably) using UTF8 on its console; the bytes are the UTF8 endianness markers. You can do: LC_ALL=C mono myexe.exe

And they wont show up.

Alternatively, you can do:

$ echo -e "\033%G"

to enable UTF-8 on the console.

Mono と ASP.NET

Question 91: Mono は ASP.NET をサポートしていますか？

ええ。

Mono supports ASP.NET, we have shown an unmodified IBuySpy installation running on Mono as well as various other programs. You can try it yourself downloading the XSP server.

Question 92: ASP.NETをmonoで実行するのに、cygwinをインストールする必要があるでしょうか、それとも既にセルフホスティング出来るのでしたらLinuxで十分なんでしょうか。

Linux で十分です。

Question 93: monoのASP.NETをLinuxのApacheで動作させる計画はありますか？

You need the Mono runtime and a hosting web server. Currently we distribute a small web server called `xsp' which is used to debug applications, or you can choose to use Daniel's Apache 2 module.

Question 94: Any plan to make ASP.NET in mono works with Apache in Linux?.

Daniel has authored an Apache2 Module for Mono that hosts the ASP.NET runtime and is available here: http://apacheworld.org/modmono/

Question 95: Will you support Apache 1?

Modules developed for Apache 2 are not compatible with Apache 1.3 Daniel plans to support Apache 1.3 in the future but the current focus is on Apache 2, because of the better support for threading and Windows.

Question 96: Can I run Apache 1 and Apache 2 on the same machine?

You can always keep a copy of Apache 2 running in parallel with your Apache 1.3 (either different port or using a reverse proxy).

You can also bind the two servers to different IP addresses on the same physical machine.

Mono と ADO.NET

Question 97: ADO.NETサポートの状態はどうなってます？ MS.NETのアプリケーションをMonoに移植する作業は始められるでしょうか？

もちろん、あなたが自分のアプリで、不足部分をあなたが開発して穴埋めするのを手伝ってくれるのでしたら:-) 今すぐにでもADO.NETサポートをmonoで使って始めることができます。いやつまり、何が言いたいかというと、われわれはまだ完全なMonoのADO.NETサポートには遠く及んでおらず、作業中の部分がたくさんあるので、もっと多くの助けを得ることが出来たら、本当にすぐにでも終わらせることができるでしょう、ということなのです:-)

Question 98: アプリケーションにおけるデータアーキテクチャの設計時に、わたしがMonoのADO.NET実装への有効な移植（最小限のコードの書き直し）を一番スムーズにする、あるいはそれを邪魔するような障害物で回避すべきものが、何かあるでしょうか？（たとえば、強く型付けされたデータセット vs. 型付けのないデータセット、とか...）

われわれは全てのクラスを Microsoft .NETのSystem.Dataで実装していますので、MSの実装と同じようにMonoも動作するであろうと確信してもらえます。

Question 99: MonoはMono.Data.*を使ってSybaseと接続できますか?

はい。Mono.Data.SybaseClientを使ってください。 まず SybaseConnection を生成して、そこから他のIDbConnection ベースのクラスを使ってください。

Mono と Java

Question 100: 何でJavaを使わないんでしょう？ 最終的にJava VMをターゲットにしている言語はたくさんあるんですけど。

自由なシステムですぐにでもJava開発できる、とても良いツールが入手できます。 Red Hat は、JavaソースやJavaバイトコードからネイティブ実行可能コードを生成する GCCの Java用フロントエンド を貢献しています; Transvirtual は Kaffe という、JavaのJITエンジンを実装しました; Intelも ORPというJava VMをもっています。

JVM は一般的な用途の仮想マシンとなるようには設計されていません。 一方で、共通中間言語 (CIL)は、幅広いプログラミング言語を対象として設計されており、またJITerにとって最適なものとなるべく設計された、ルールのセットをもっています。

Question 101: Java は CLI をターゲットに出来ますか？

ええ、JavaはCLIをターゲットにすることもあり得ますし、Microsoft J#はそれをやっています。

The IKVM project builds a Java runtime that works on top of .NET and on top of Mono. IKVM is essentially a JIT compiler that translates from JVM bytecodes into CIL instructions, and then lets the native JIT engine take over.

Question 102: JVMバイトコードをCILコンバータ用に書くことができますか？

はい、それが IKVM がやっていることです。

Question 103: monoはCILとjavaのハイブリッド プラットフォームになることができますか？

IKVMで簡単に実現できます。

Question 104: Do you plan to implement a Javascript compiler?

Yes. The beginnings of the JScript compiler can be found on CVS. Cesar coordinates this effort.

Question 105: Can Mono or .NET share system classes (loaded from mscore.dll and other libs) or will it behave like Sun's Java VM?

What you can do with mono is to load different applications in their own application domain: this is a feature of the CLR that allows sandboxing applications inside a single process space. This is usualy exploited to compartmentalize different parts of the same app, but it can also be effectively used to reduce the startup and memory overhead. Using different appdomains the runtime representation of types and methods is shared across applications.

Question 106: Monoあるいは.NETは、SunのJava VMのように、システムクラス（mscore.dllや他のライブラリからロードされるもの）を共有することが出来ますか?

あなたがmonoでできることは、そのアプリケーション ドメイン自身の中で、 別のアプリケーションをロードすることです: 単一のプロセス空間内でアプリケーションのサンドボックスを許容するというのは、CLRの失敗です。これは通常、同一のアプリケーションの別の部品を区切るという使い方をするのですが、スタートアップとメモリのオーバーヘッドを効率的に減らすためにも使われます。 別の appdomain を使って、型およびメソッドのランタイム表現は、アプリケーション間で横断的に共有されます。[訳注 - 「プログラミング Microsoft .NET Framework」の20章に詳しい説明がある]

Monoの拡張

Question 107: 仕様にないクラスを作っても良いですかね？

どうぞ。Microsoftのクラスコレクションは非常に膨大ですが、これが完全であるということは決してありません。Monoアプリケーション用に`Camel' (Java Mailにインスパイアされた、Evolutionで使われているメールAPI)の移植を作れればナイスですね。

Mono用のCORBAの実装にあたってみたいと思われるかもしれません。 それは便利なだけでなく、CLIがタイプリッチなシステムであるという事実を考えると、面白そうな話に聞こえます。

Monoを拡張するための詳しい情報については、われわれのアイディアのページを見て下さい。

Question 108: .NETを取り込んで拡張する[Embrace and Extend]計画はありますか？

優れた技術の取り込みは良いことです。技術を非互換のかたちで拡張するのは、ユーザーにとっては悪いことですので、この技術を拡張する計画はありません。

もし革新的なアイディアがあって、新しいクラスを作りたいということでしたら、われわれはそれらのクラスを、Monoでも.NETでも正しく動作するように作ることを推奨します。

Today Mono ships with a number of extra libraries that were developed either by members of the Mono community, or other groups.

In some cases, we have found the bits from Microsoft to be incomplete, but we avoid breaking the API, instead we expose the missing functionality in new assemblies (See Mono.Security and System.Security).

Question 109: Is there any way I can develop the class libraries using Linux yet?

Yes. Mono has been selfhosting since March 2002.

Question 110: monoの動作確認済みのコピーを /usr の中にインストールして、実験的なコピーを他の場所に置いて、両方のコピーがそれぞれのライブラリを使うようにすることができますか？（私、Linuxのライブラリパスをまだよく知らないんです）

ええ。単純に、インストール時プレフィックスを2つ使ってください。

移植性

Question 111: MonoはLinuxでしか動作しませんか？

のところ、われわれはLinuxベースのシステムとWindowsで作業を進めています。われわれはコードにLinux主義にならないことを期待していますので、Monoを他のUNIXの変形[Unix variants]に移植するのは簡単であるべきです。

Question 112: Monoを非Linuxベースのシステムに持っていくのはどうですか？

Ximianにおけるわれわれの主要な意図は、GNOMEアプリケーションをMonoで開発することができるようになることです。が、もしあなたがWinformクラスを他のプラットフォーム（たとえば、frame bufferやMaxOS Xなど）に移植することに興味があれば、われわれはそれがオープンソースライセンスのもとで行われる限りは、それを喜んで統合します。

Question 113: どのオペレーティングシステム/CPUをサポートしていますか？

Monoは現在のところ、Linux、Windows、Solaris、FreeBSD, HP-UX, MacOS X上で動作しています。

x86プロセッサ用には、特定のCPU向けのコードの生成と最適化を行うことができるJITエンジンがあります。

SPARC v8, SPARC v9, Itanium, HP-PA, PowerPC, StrongARM の各CPUについては、インタープリタが存在します。

Question 114: MonoはWindowsで動作しますか？

はい。プリコンパイルされたバイナリを binaries from http://www.go-mono.com/download.htmlから入手できます。

Question 115: MonoはLinuxで動作しますか？

はい。プリコンパイルされたバイナリを binaries from http://www.go-mono.com/download.htmlから入手できます。

Question 116: monoを実行するにはcygwinが必要ですか？

いいえ。CygwinはMonoをビルドするときにだけ必要となります。

Question 117: Mono は GNOME に依存するようになるでしょうか？

特定のアセンブリを使おうとする時だけ依存するでしょう（たとえば、GUIアプリケーションをやってるときには）。あなたが「Hello WorldエンタープライズP2P Webサービス」を実装することしか興味がないのでしたら、GNOMEのコンポーネントは何も必要ありません。

Question 118: RhinoをC#に移植する計画はありますか？

Eto Demerzal が Rhinoの C#移植を始めています。

Question 119: MacバージョンのC#環境のビルドに成功した人はいますか？ いるとしたら、どうやったか説明してくれませんか？

はい。Mono はLinux/PPC および MacOS X (10.2 and 10.3)上で動作します。

既存コードの再利用

Question 120: あなたたちは、どのプロジェクトを再利用したり、土台にして設計するつもりですか？

われわれは近いうちにMonoをプログラマーの手に渡したいと思っています。われわれは既存のオープンソース ソフトウェアの再利用には関心があります。

Question 121: Microsoft SQL Server 2000 を使えるようになるでしょうか、あるいは特定のオープンソース データベースに切り替えることが必要でしょうか？ 再コードは必要ですか？

再コードする必要は無いでしょう。

Question 122: VB.NETでプログラミングするときに、それらのアプリケーションがLinuxで実行できることを確信できるようにするには、何を見る必要があるでしょうか？

PInvokeやDLL呼び出しを作り出したり、Microsoft.* ネームスペースのものを使わないことで十分です。また、「この型は、.NET Framework インフラストラクチャのサポートを目的としています。独自に作成したコード内で直接使用することはできません。」[English Versionなら "This type/method supports the .NET Framework infrastructure and is not intended to be used directly from your code."]とマークされているメソッドやクラスはいずれも、たとえ動くと知っていても使わないことです。

Question 123: crystal reports用のビルトインのレポーティングはサポートされますか？ これが私たちのシステムの一部でヘビィに使われているんですが。

多分しません。Crystal Reports はプロプラエタリなものです。誰かがその振る舞いをエミュレートしようとするかもしれませんが、まだ誰もそういうボランティアはやっていないです。

Question 124: レジストリに書き込む奴についてはどうですか？ 私が理解しているところでは、Linuxはレジストリになるものはもっていません。あの機能に依存するのは避けるべきでしょうか？

避けるようにしてください。Monoでもレジストリのエミュレーションが出来るようにはなるでしょう。しかし、gnomeはレジストリに近いコンフィグレーションシステムを持っているのですが、そのキーは同じものにはならないでしょうから、結局はあなたはおそらく何かしらのランタイム検出を行わなければならなくなるでしょうし、あなたのプラットフォーム固有のやっつけ仕事で作ったそのアセンブリのロードに依存することになるでしょう。

Question 125: System.Data.SqlClient と FreeTDSについてですが、C#にそれらの一部を移植したり、使ったりするでしょうか？

出来ています。

Mono と GCC

Question 126: C#のGCCフロントエンドの作業はやっていますか？ CILイメージを生成するGCCバックエンドは？ CILイメージを受け取ってネイティブコードを生成するGCCフロントエンドはどうでしょう？

われわれは現在、それらのプロジェクトのボランティアを探しているところです。興味がおありでしたら、協力のセクションを見てください。

Question 127: What about making a front-end to GCC that takes CIL images and generates native code?

There is no active work on this area, but Mono already provides pre-compilation services (Ahead-of-Time compilation).

Question 128: でもそれらの作業はGCCコンパイラのGPLのものになるわけですし、フリーでないフロントエンドで皆さんが作業することを許してしまうのではないでしょうか？

皆さん既にJVMバイトコードをターゲットにして、それが出来ています（JVMをターゲットにした、多様な言語のためのコンパイラが130近くあります）。

パフォーマンス

Question 129: Monoはどれくらい速いものになるでしょうか？

われわれは未来を予言することは出来ません。しかし、慎重な見積としては、最低でも「他のJITエンジンと同程度には高速なもの」になるでしょう。

われわれは、ちょうどMicrosoftが彼らの.NET開発プラットフォームについて行っているのと同じように、さまざまなJITエンジンと一緒にMonoを出荷したいのです。われわれは、より高速な、低パフォーマンスで高速ロードのJITや、コード生成時は低速だけどより最適化された出力を生成するような最適化JITを提供することもできました。

Mono's JIT engine has been recently re-architected, and it provides many new features, and layers suitable for optimization. It is relatively easy to add new optimizations to Mono.

CILはJavaバイトコードに対して、いくらかアドバンテージになるものです: これは本当の中間表現であり、より良いJITエンジンの作成を簡潔にするCILコードをエミットできるようにするために、数多くの制限が設けられています。

たとえば、CIL上では、スタックはコードジェネレータが好きなように使うことができるアブストラクションではありません。そうではなく、これは解析されたツリーのポストフィックス表現を作成する方法なのです。いかなる呼び出し位置や戻り位置でも、スタックの内容は、命令がどこまで到達しているかに関わらず、同一のオブジェクトタイプを含んでいることが期待されます。

ライセンス

Question 130: Monoで動作する、プロプラエタリなアプリケーションを書くことはできますか？

ええ。ライセンスのスキームは、プロプラエタリな開発者がMonoでアプリケーションを設計することを許容するよう計画されています。

Question 131: Monoプロジェクトでは、どういうライセンスを使っているのですか？

C#コンパイラはGNU GPLの下でリリースされています。ランタイムライブラリはGNU ライブラリ GPLです。クラスライブラリはMIT X11ライセンスの文言に沿ってリリースされています。

LGPLのことを"Lesser GPL"とは呼ばず、"Library GPL"と書いていることに注意。

MonoランタイムとMono C#コンパイラは、LGPLやGPLをコードに使えない人には、プロプラエタリなライセンスの下でも利用することができます。

ライセンスの詳細については、mono-licensing@ximian.comに連絡してください。

Question 132: Monoに特別なライセンスの下でコードを貢献したいんですけど、どんなライセンスなら受け容れてもらえますか？

われわれはまずそのライセンスの互換性を評価しなければならないでしょう。しかし一般的なルールとして、その「コンテナ」モジュールと同一のライセンスの下でそのコードを受け容れます。

特許

Question 133: Monoを完全に禁圧するために特許が利用されることがありえますか？（現在出願されているサブマリン特許や、Microsoftによって特に特許問題を作り出すために変更されたりなどで）

First some background information.

The .NET Framework is divided in two parts: the ECMA/ISO covered technologies and the other technologies developed on top of it like ADO.NET, ASP.NET and Windows.Forms.

Mono implements the ECMA/ISO covered parts, as well as being a project that aims to implement the higher level blocks like ASP.NET, ADO.NET and Windows.Forms.

The Mono project has gone beyond both of those components and has developed and integrated third party class libraries, the most important being: Debugging APIs, integration with the Gnome platform (Accessibility, Pango rendering, Gdk/Gtk, Glade, GnomeUI), Mozilla, OpenGL, extensive database support (Microsoft only supports a couple of providers out of the box, while Mono has support for 11 different providers), our POSIX integration libraries and finally the embedded API (used to add scripting to applications and host the CLI, or for example as an embedded runtime in Apache).

The core of the .NET Framework, and what has been patented by Microsoft falls under the ECMA/ISO submission. Jim Miller at Microsoft has made a statement on the patents covering ISO/ECMA, (he is one of the inventors listed in the patent): here.

Basically a grant is given to anyone who want to implement those components for free and for any purpose.

The controversial elements are the ASP.NET, ADO.NET and Windows.Forms subsets. Those are convenient for people who need full compatibility with the Windows platform, but are not required for the open source Mono platform, nor integration with today's Mono's rich support of Linux.

The Mono strategy for dealing with these technologies is as follows: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless. 特許された機能を提供しないことは、インターオペラビリティを悪化させるものではなく、むしろ、Monoの開発の第一の理由である、自由なソフトウェア / オープンソース ソフトウェアのコミュニティに、良い開発ツールを提供するということになります。

The patents do not apply in countries where software patents are not allowed.

For Linux server and desktop development, we only need the ECMA components, and things that we have developed (like Gtk#) or Apache integration.

Question 134: Is Mono only an implementation of the .NET Framework?

Mono implements both the .NET Framework, as well as plenty of class libraries that are either Unix specific, Gnome specific, or that are not part of the .NET Framework but people find useful.

The following map shows the relationship between the components:

Obfuscation

Question 135: Are there any obfuscation programs for Mono/Linux?

We are not aware of these, but some from Windows might work.

Question 136: What could I do to avoid people decompiling my program?

You can use the bundle functionality in Mono.

This would bundle your binary inside a Mono runtime instance, so you distribute a single executable that contains the code inside. Notice that for this to work and be practical, you need to get a commercial license to the Mono runtime.

The reason is that the bundle functionality is covered by the LGPL: so you would have to distribute your assemblies separatedly to allow developers to relink mono which would defeat the purpose of bundling for obscuring your code.

It is not impossible to break, just like any other obfuscators.

That being said, value these days does not lie in particular tiny routines, but lies in the large body of work, and if someone steals your code, you are likely going to find out anyways.

Question 137: Any other option?

You could precompile with --aot your code, then disassemble the original .exe, and remove all the code, then re-assemble and ship both the vessel .exe and the precompiled code.

This is not a supported configuration of Mono, and you would be on your own in terms of dealing with bugs and problems here.

Get the companies that build the obfuscation packages to read the ECMA spec and fix the bugs in their products that generate non-standard binaries (or, if they expose a bug in mono, please file a report in our bugzilla).

Pay Ximian/Novell to spend the development time needed to get mono to support the broken binaries that some of the obfuscation packages generate (or contribute that support).

その他の質問

Question 138: あなたたちは、CLIは複数の言語が同じ環境で実行できるものだと言いましたが、それはCORBAの目的ではありませんか？

CORBA（あるいはCOM）とCLIの重要な違いは、CLIは「データレベルのインターオペラビリティ」を許容するということです。というのは、全ての言語/コンポーネントが、同一のデータレイアウトとメモリ管理を使うからです。

これは、あなたが他の誰かが提供したデータ型を、彼らのインターフェースを介することなく直接操作することができる、ということです。これは、あなたがパラメータを「マーシャル」（コンバート）する必要がなく（データレイアウトが同一なので、あなたはコンポーネントを直接渡すことができるのです）、また、全ての言語/コンポーネントが同一のガベージコレクタとアドレス空間を共有するので、メモリ管理についても心配する必要がないということでもあります。これはコピーなどではありませんし、また参照カウンタも必要ありません。

Question 139: COMはサポートしますか？

ランタイムでは、UnixシステムではXPCOMを、WindowsではCOMをサポートすることになるでしょう。ダイナミック トランポリンのためのコードの大部分は既に準備できています。

Question 140: Ximian はMonoや関連技術の証明書を提供しますか？

それは可能ですが、計画はありません。つまり、簡潔に言えば否です。

Question 141: バグはどうすれば報告できますか？

一番良いのは、バグを追跡して、バグを再現する簡単なテストを提供してくれることです。そうしたら、あなたはそのバグをバグ追跡システムに追加してください。

あなたが使っているmonoのバージョン情報と、そしてバグを再現できる詳細情報を何でも提供してください。ご参考までに、メーリングリスト上で報告されたバグは簡単に忘れられてしまいますので、バグ追跡システムにそれを記録しておいてもらえた方が良いです。

Question 142: mcsはMSのC#コンパイラと同じコマンドラインオプションをサポートしますか？

Mono C# コンパイラは今ではMicrosoft C# コンパイラの引数と同じものをサポートしています。

Question 143: lists.ximian.comのアーカイブを検索可能にするというのはどうですか？

mono関連のメーリングリストの検索はここから実行できます。

Question 144: cvsやスナップショットからmonoを使っていると、Monoとランタイムが同期していないというエラーメッセージを受け取ります。どうやって直せば良いですか？

monoをcvsから使っているときは、ランタイム内部の変更も待つ必要があります。これはつまり、無闇にアップデートをかける前に、実行できるセットアップを維持しておくべきだということです（実行できるセットアップとしては、単純に、最新のリリースtarballや最新のバイナリ スナップショットがありえます）。 通常は、Cランタイムを再コンパイルする前にcorlibをmcsでコンパイルすれば、上手く事が運びます（ただ、運が悪ければ他の手段をとる必要があるかもしれません）。

Question 145: なぜあなたがたは GtkHtmlの実装に向かっているのですか?

GtkHTMLはCSSをサポートしない、軽量なHTMLレンダリングエンジンで、 われわれはLinux上での日々の作業で、適切にドキュメントを使うために、 必要としているのです。 あなたがドキュメントをブラウズするWebベースのインターフェースには、 ネイティブのGUIツールのような軽快さはありません。おそらく後々、われわれは スクリプトを書いて、webで表示可能なドキュメントを全て生成するでしょう。 しかしわれわれは、Webに接続していない時には、Linux上でネイティブ に使うことが可能な（そして、webページよりまともなインタラクションがある） コマンドラインとGUIのツールを必要としているのです。

Question 146: .NETにインタラクティブにアクセスさせてくれるような、コマンドラインツールはありませんか?

いろんなものがありますが、自由なソフトウェアでMCSを使っているもので、 Rice UniversityのDennis Lu fromが作業している、REPL C# インタープリタがあります。

Question 147: MonoにVisual C++を使うことが出来ますか?

ええ、VC++が生成したアプリケーションであっても、Monoで実行することは可能です。ただし、私たち自身はmanaged C++コンパイラを提供していません。

Question 148: Does Mono support generics?.

Mono doesn't support generics currently but a lot of work is being done towards it.

Mono全般の問題

もしあなたが、Monoソフトウェアのコンパイルや実行について問題があったり、バグを見つけたと思ったら、 Mono 全般の問題 の文書にあたってみて下さい。

Credits

The FAQ contains material contributed by Miguel de Icaza, Jaime Anguiano, Lluis Sanchez.