我只是想知道，如果任何语言的所有编译器都将代码转换为计算机内部“对话”的唯一语言（机器代码 - 零和一），为什么将 .NET Windows 应用程序传递给 Mac 应用程序如此困难？
不应该有人提出一个绝妙的主意（自从我 3 年前结婚以来，我就没有绝妙的主意！）并且有一个......我不知道......一个机器代码框架，而不是编译器转换为机器代码，它将转换为该框架，该框架将安装在任何平台（SuSE、fsb、Ubuntu、AIX、SCO、OS X、Windows 9x、Vista、7 等）中。
我想知道为什么我们不能这么简单地做事，这些天...
有什么想法吗？
事实上，它已经完成了。至少在一定程度上。
其中一项工作称为 Java，它是一种跨平台语言。Java 编译器将源代码编译成一种叫做“字节码”的东西，它只不过是一种与机器无关的“汇编语言”。那个“可执行文件”后来被Java虚拟机（JVM）执行，这是不同平台的部分（即Windows JVM明显不同于MacOS JVM）。
但是，跨平台应用程序并不是那么简单。编写一个可以为每个可能的平台执行某种抽象字节码的基本 VM 相对简单。但是，如果语言本身缺乏丰富的类库，它实际上什么都不是。因此，由于各种原因，实现上述类库是一件非常困难的事情。
这个问题比大多数人提出的要深，Java 仍然不是真正独立于平台的，因为它不会在所有 x86 或 x64 操作系统上运行，你仍然需要一个虚拟机才能在操作系统上运行。它甚至不接近您的建议，因为您仍然需要依赖于操作系统的运行时来执行“独立”字节码。
问题在于大多数可执行文件都覆盖了操作系统并将其用作一种框架。一旦您将某种操作系统相关的代码放入您的应用程序中，您就失去了使其独立的机会。磁盘 IO、网络 IO、图形 UI、获取系统信息，这些事情中的任何一个都会影响您的代码如何以及为什么不能独立。
还有一个可执行文件是什么的问题，在 windows 上你有PE，而在大多数 linux 操作系统上你有ELF。它们具有不同的结构和不同的加载方式。它们如何加载和执行取决于操作系统，而不是可执行文件的问题。
您可以在此图像中看到两种格式之间的区别（取自此处： http: //software.intel.com/file/9800
基本上，问题在于对于可执行/二进制文件的结构化和加载到计算机的方式没有标准。然后，最重要的是操作系统的框架和功能。这是一个复杂得多的问题，但只要公司想要拥有特定于操作系统的功能，就无法解决这个问题。
应用程序依赖于操作系统来提供服务。
您可以创建一个对操作系统的依赖性最小的应用程序。但即使（通过一些严肃的 Fu、Magic 和挥手）你让它在“每台计算机”上运行，这也不是我们想要的。
脚本和类脚本语言（如前面提到的 Python 和 Perl）就是这样：它们使用操作系统的最少功能，并在其之上构建它们提供的所有内容。这对于命令行应用程序来说非常有用，因为您需要（或多或少）读取和写入文件和用户控制台。
然而，今天的丰富应用程序需要更多的服务，它们需要“在操作系统上运行”而不是单独“在 CPU 上”：我们希望它们与操作系统集成，用户界面应该看起来是原生的，你想使用剪贴板， “打开文件”对话框应提供其他打开文件对话框提供的所有功能。
像 Java 这样的环境试图通过使用更高级别的抽象以可移植的方式提供它：有窗口和小部件以及所有美丽的东西。但这有其自身的一些问题：
首先，您必须始终在“虚拟化平台一致性”（即应用程序无论在何处运行都一样）和“主机平台一致性”（即应用程序像本地应用程序一样工作）之间取得平衡。
您可以尝试完全放弃“原生内容”以避免该问题，但随后您的目标是所有平台提供的功能的交集。你在苹果上运行？取消第二个鼠标按钮。等等。此外，您的抽象平台将始终落后于主机平台的创新。
我们可以这样做，以 Java 为例。微软是否会这样做是另一个问题。他们通过不这样做来保持 Windows 的竞争优势。
其他示例是 Perl 和 Python，仅举两个例子。仅仅有一种语言是不够的，你需要有库来让程序员的生活更轻松。Java、Python 和 Perl 似乎相对较好地实现了这一点，我相信微软有能力为 .NET 做同样的事情。但问题仍然存在：他们为什么要这样做？
远离字节码类型的虚拟机，您还拥有诸如 VMWare、Virtual PC 等可以在硬件级虚拟处理器上运行代码的东西。其中一些需要在后台使用相同的处理器，其他（我相信像 VirtualBox 和 Bochs）在不同的处理器之上运行虚拟处理器。
我还没有真正看到的是主机和虚拟环境之间的无缝集成。VMWare 在两者之间的拖放是可以的，但如果能够在 x86 之上托管 SPARC 环境并且基本上让 SPARC 应用程序看起来与 x86 应用程序完全一样（类似于 Cygwin 的 X-windows基于 - 的应用程序看起来就像普通的 Windows 窗口。
问题总是你会得到一个低于标准的应用程序。
如果一个应用程序需要在所有平台上运行，那么您最终会得到一个无法正确适配任何平台的 GUI，以及一个缺少平台上预期功能的应用程序，即仅存在于一个平台上的功能 - 在 OS X 上，您希望与所有最新功能，smae 适用于 Windows 和 *nix
我猜你能得到的最接近的是拥有跨平台的核心功能，然后在上面构建 GUI 和任何其他特定于平台的功能。
正如其他人已经提到的，这是可能的（尤其是基于 JVM 的语言和 Python），并且许多人确实创建了跨平台应用程序。令我吃惊的是坚持使用平台相关框架的人数之多。显然，它们的营销效果更好。
这些事情更多地与政治问题有关，而不是与技术问题有关。在实践中，跨平台开发最苛刻的技术问题来自低级硬件通信（驱动程序到特定设备等），但典型的应用程序无论如何都不需要直接与硬件通信。
Microsoft 仅在 Windows 上实现了 .NET。因此，要让 .NET 应用程序在其他平台上运行，就需要一个新的实现。Mono正在采取措施使这成为可能。当前版本运行大多数 .NET 2.0 程序集并支持许多特定于 Windows 的接口。
至于您的其余问题：重新实现其他所有人使用的所有 API 都很难，现有项目也不完整。Wine支持大多数 Windows 应用程序，但仅支持。GNUstep实现了大部分 OpenStep 规范，并且与 Mac OS 的 Cocoa API 有一些兼容性，但它的不完整令人痛苦，并且会持续很长时间。
如果每个人都使用一种标准的 API，也许情况会有所不同。但是，坦率地说，现有的所有 API 在某种程度上都很糟糕。
为什么将 .NET windows 应用程序传递给 Mac 应用程序如此困难？
.NET 旨在作为程序员构建Windows程序的框架。.NET 的完整实现（由 MS 完成）仅适用于 Windows。似乎没有太大希望，这会改变。
为了获得更好的跨平台支持，您可能需要查看其他语言，例如 Java 1：
Java 应用程序通常被编译为可以在任何 Java 虚拟机 (JVM) 上运行的字节码
...这与 python 所做的非常相似2：
CPython 将 Python 程序编译成中间字节码，然后由虚拟机执行。
即使 .NET 做同样的事情3：
此运行时环境也是 .NET Framework 的一部分，称为公共语言运行时 (CLR)。CLR 提供应用程序虚拟机的外观
问题是“虚拟机”——由 MS 定义和构建——仅在 Windows 上可用：
.NET 的完整形式仅在 Windows 平台上可用
好吧，您可以使用 Silverlight。至于 Silverlight 是否从浏览器转移到原生应用程序，这是微软的政治决定，而不是技术问题。Mono 的家伙们还致力于让 .net 构建 iPhone 二进制文件，因此毫无疑问将来会获得更多的跨平台。
Adobe Air、Java 和其他类似的东西也制作跨平台客户端应用程序 - 地狱，如果你真的想的话，你甚至可以用 C++ 做跨平台:-)