为什么我们这些天不能创建跨平台的程序？

我只是想知道,如果任何语言的所有编译器都将代码转换为计算机内容中唯一的"谈话"语言(机器代码 - 零和1),为什么将.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操作系统上运行,你仍然需要一个VM来运行在操作系统的顶上.它甚至不接近您的建议,因为您仍然需要依赖OS的运行时来执行"独立"字节码.

问题在于大多数可执行文件覆盖操作系统并将其用作一种框架.只要将某种类型的操作系统相关代码放入应用程序中,就会使您无法使其独立.光盘IO,网络IO,图形用户界面,获取系统信息,这些都将影响您的代码无法独立的方式和原因.

还有可执行文件的问题,在Windows上有PE,而在大多数Linux操作系统上你有ELF.它们具有不同的结构和不同的加载方式.如何加载和执行它们取决于操作系统,而不是可执行文件的问题.

您可以在此图像中看到两种格式之间的差异(摘自此处:http: //software.intel.com/file/9800

基本上问题是,可执行文件/二进制文件的结构和加载到计算机的方式没有标准.然后,最重要的是操作系统的框架和功能.这是一个更复杂的问题,但只要公司希望拥有特定于操作系统的功能,这个问题就无法解决.

应用程序依赖于操作系统来提供服务.

您可以创建一个对操作系统的依赖性最小的应用程序.但即使(有一些严肃的Fu,Magic和handwaving)你让它在"每台计算机"上运行,它也不是我们想要的.

类似脚本和脚本的语言(如上所述的Python和Perl)就是这样:它们使用操作系统的最小功能,并构建它们提供的所有功能.这对于命令行应用程序来说非常棒,因为您只需要(或多或少)读取和写入文件以及用户控制台.

今天丰富的应用程序需要更多的服务,它们需要"在操作系统上运行"而不是"在CPU上运行":我们希望它们与操作系统集成,UI应该看起来是原生的,你想要使用剪贴板, "打开文件"对话框应提供其他打开文件对话框提供的所有功能.

像Java这样的环境试图通过使用更高级别的抽象以可移植的方式提供它:有窗口​​和小部件以及所有美丽的东西.但这有一些问题:

首先,您必须在"虚拟化平台一致性"(即应用程序无论您在何处运行它都相同)和"主机平台一致性"(即应用程序像本机应用程序一样工作)之间取得平衡.

您可以尝试完全放弃"本机内容"来避免这个问题,但是您的目标是所有平台提供的功能交叉.你在Apple上运行？取消第二个鼠标按钮.此外,您的抽象平台将始终躲在主机平台上的创新.