任意の言語のすべてのコンパイラがコードをコンピューターの内部で「話す」唯一の言語 (マシン コード - 0 と 1) に変換する場合、なぜ .NET Windows アプリケーションを Mac アプリケーションに渡すのが難しいのでしょうか?
誰かが素晴らしいアイデアを思いつき (私は 3 年前に結婚して以来、私は素晴らしいアイデアを持っていません!)、... わからない ... マシン コード フレームワークを持っているべきではないので、コンパイラが変換する代わりにマシン コードは、そのフレームワークに変換され、任意のプラットフォーム (SuSE、fsb、Ubuntu、AIX、SCO、OS X、Windows 9x、Vista、7 など) にインストールされます。
なんでこんなに簡単にできないんだろう、最近は…
何かご意見は？
実際、それはすでに行われています。少なくともある程度。
その取り組みの 1 つが、クロスプラットフォーム言語である Java と呼ばれるものです。Java コンパイラは、ソースを「バイトコード」と呼ばれるものにコンパイルします。これは、マシンに依存しない「アセンブリ言語」にすぎません。その「実行可能ファイル」は、プラットフォームごとに異なる部分である Java 仮想マシン (JVM) によって後で実行されます (つまり、Windows JVM は MacOS JVM とは明らかに異なります)。
ただし、クロスプラットフォーム アプリはそれほど単純ではありません。考えられるすべてのプラットフォームである種の抽象的なバイトコードを実行する基本的な VM を作成するのは比較的簡単です。しかし、豊富なクラス ライブラリがなければ、言語自体はほとんど意味がありません。そのため、上記のクラス ライブラリを実装することは、さまざまな理由から非常に難しいことです。
この問題は、ほとんどの人が考えているよりも深刻です。Java はすべての x86 または x64 OS で実行されるわけではないため、プラットフォームに依存しないわけではありません。OS 上で実行するには VM が必要です。「独立した」バイトコードを実行するには、OSに依存するランタイムが必要なため、提案したものにはほど遠いです。
問題は、ほとんどの実行可能ファイルが OS をオーバーレイし、それを一種のフレームワークとして使用しているという事実に伴います。ある種の OS 依存コードをアプリケーションに配置するとすぐに、それを独立させるチャンスが台無しになります。ディスク IO、ネットワーク IO、グラフィカル UI、システム情報の取得、これらのいずれも、コードが独立できない方法と理由に影響を与えます。
また、実行可能ファイルとは何かという問題もあります。Windows ではPEを使用しているのに対し、ほとんどの Linux OS ではELFを使用しています。これらには、異なる構造と異なる読み込みスタイルがあります。それらがどのように読み込まれて実行されるかは、実行可能ファイルの問題ではなく、OS 次第です。
この画像で 2 つの形式の違いを見ることができます (ここから取得: http://software.intel.com/file/9800
基本的に問題は、実行可能ファイル/バイナリ ファイルを構成してコンピュータにロードする方法に標準がないことです。その上に、OS のフレームワークと機能があります。これははるかに複雑な問題ですが、企業が OS 固有の機能を持ちたいと考えている限り、解決することはできません。
例として Java を参照してください。Microsoftがそれを行うかどうかは別の問題です。彼らは、それを行わないことで、Windows の競争上の優位性を維持しています。
他の例としては、Perl と Python が 2 つだけ挙げられます。言語を持っているだけでは十分ではありません。プログラマーの生活を楽にするライブラリが必要です。Java、Python、および Perl は、これを比較的うまく達成しているように見えます。Microsoft には、.NET に対して同じことを行う頭脳があると確信しています。しかし、疑問は残ります。なぜ彼らはそうするのでしょうか?
バイトコード タイプの VM から離れて、VMWare、Virtual PC など、ハードウェア レベルの仮想プロセッサでコードを実行できるものもあります。これらの中には、内部で同じプロセッサを必要とするものもあれば、別のプロセッサ上で仮想プロセッサを実行するもの (VirtualBox や Bochs など) もあります。
私が実際に見たことがないのは、ホスト環境と仮想環境の間のシームレスな統合です。VMWare の 2 つの間のドラッグ アンド ドロップは問題ありませんが、x86 上で SPARC 環境をホストでき、基本的に SPARC アプリが x86 アプリとまったく同じように見える (Cygwin の X-windowsベースのアプリケーションは、通常の Windows ウィンドウのように見えます。
問題は常に、標準以下のアプリケーションを取得することです。
アプリケーションがすべてのプラットフォームで動作する必要がある場合、どのプラットフォームにも正しく適合しない GUI になり、プラットフォームで期待される機能 (つまり、1 つのプラットフォームにのみ存在する機能) を欠くアプリケーションになります。OS X では、すべての最新機能。Windows と *nix にも最適です。
私が推測できる最も近い方法は、コア機能をクロスプラットフォームにし、その上に GUI と追加のプラットフォーム固有の機能を構築することです。
他の人が既に述べたように、それは可能であり (特に JVM ベースの言語と Python)、多くの人がクロスプラットフォーム アプリを作成しています。私が驚いたのは、プラットフォームに依存するフレームワークに固執する人の数です。どうやら彼らはよりよく販売されています。
これらは、技術的な問題よりも政治的な問題に関係しています。実際には、クロスプラットフォーム開発で最も要求の厳しい技術的問題は、低レベルのハードウェア通信 (特定のデバイスへのドライバーなど) から発生しますが、通常のアプリはハードウェアと直接通信する必要はありません。
.NET WindowsアプリケーションをMacアプリケーションに渡すのが難しいのはなぜですか？
.NETは、プログラマーがWindowsプログラムを構築するためのフレームワークとして意図されています。.NETの完全な実装（MSによって行われる）は、Windowsでのみ使用できます。これが変わるという希望はあまりないようです。
クロスプラットフォームのサポートを改善するには、Java1などの他の言語を確認することをお勧めします。
Javaアプリケーションは通常、任意のJava仮想マシン（JVM）で実行できるバイトコードにコンパイルされます。
...これはPythonが行うことと非常によく似ています2：
CPythonは、Pythonプログラムを中間バイトコードにコンパイルします。中間バイトコードは、仮想マシンによって実行されます。
.NETは同じことをしますが3：
.NET Frameworkの一部でもあるこのランタイム環境は、共通言語ランタイム（CLR）として知られています。CLRは、アプリケーション仮想マシンの外観を提供します
問題は、MSによって定義および構築された「仮想マシン」がWindowsでのみ使用できることです。
完全な形式の.NETは、Windowsプラットフォームでのみ使用できます。
Microsoft は、Windows にのみ .NET を実装しています。したがって、.NET アプリケーションを他のプラットフォームで実行するには、新しい実装が必要です。Monoはこれを可能にするための措置を講じています。現在のバージョンは、ほとんどの .NET 2.0 アセンブリを実行し、多くの Windows 固有のインターフェイスをサポートしています。
あなたの質問の残りの部分について: 他の誰もが使用しているすべての API を再実装することは難しく、既存のプロジェクトは不完全です。Wineはほとんどの Windows アプリケーションをサポートしていますが、それだけです。GNUstepは OpenStep 仕様のほとんどを実装しており、Mac OS の Cocoa API とある程度の互換性がありますが、残念ながら不完全であり、長い間使用されるでしょう。
誰もが 1 つの標準 API を使用した場合、おそらく異なるものになるでしょう。しかし、率直に言って、存在するすべての API は何らかの形で最悪です。
まあ、Silverlight を使えばそれも可能です。Silverlight がブラウザーからネイティブ アプリに移行するかどうかは、技術的な問題ではなく、Microsoft の政治的な決定です。Mono 関係者は、iPhone バイナリをビルドするために .net を取得する作業も行っているため、今後クロス プラットフォームが増えることは間違いありません。
Adobe Air、Java などもクロス プラットフォームのクライアント サイド アプリを作成します。本当にやりたい場合は、C++ でクロス プラットフォームを実行することもできます :-)