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

时间:2009-02-13 10:19:37

标签: frameworks machine-code

我只是想知道,如果任何语言的所有编译器都将代码转换为计算机内容中唯一的“谈话”语言(机器代码 - 零和1),为什么将.NET Windows应用程序传递到Mac很难应用

不应该有人带来一个绝妙的主意(自从我3年前结婚以来,我没有出色的想法!)并且有...我不知道...机器代码框架所以,而不是编译器转换为机器代码,它将转换为该框架,将安装在任何平台(SuSE,fsb,Ubuntu,AIX,SCO,OS X,Windows 9x,Vista,7等等)。

我想知道为什么我们这些日子不能做这么容易的事情......

有什么想法吗?

9 个答案:

答案 0 :(得分:13)

事实上,它已经完成了。至少在一定程度上。

其中一项工作称为Java,这是一种跨平台语言。 Java编译器将源编译为称为“字节码”的东西,它只不过是与机器无关的“汇编语言”。该“可执行文件”稍后由Java虚拟机(JVM)执行,这是不同平台之间的部分(即,Windows JVM明显不同于MacOS JVM)。

但是,跨平台应用并不那么简单。编写一个基本的VM可以相对简单,它可以为每个可能的平台执行某种抽象字节码。但是,如果缺少丰富的类库,语言本身几乎没有任何意义。因此,出于各种原因实现所述类库是一件非常困难的事情。

答案 1 :(得分:11)

这个问题比大多数人所说的要深,Java仍然不是真正的平台独立,因为它不能在所有x86或x64操作系统上运行,你仍然需要一个VM来运行在操作系统的顶上。它甚至不接近您的建议,因为您仍然需要依赖OS的运行时来执行“独立”字节码。

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

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

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

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

答案 2 :(得分:5)

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

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

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

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

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

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

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

<小时/> 它的要点是没有银弹:你必须做出妥协。在市场上有不同的妥协方案。

答案 3 :(得分:3)

我们可以这样做,请参阅Java示例。 Microsoft 是否会这样做是另一个问题。他们通过不这样做来保持Windows的竞争优势。

其他例子是Perl和Python,仅举两例。仅仅拥有一种语言是不够的,你需要拥有库来使程序员的生活更轻松。 Java,Python和Perl似乎已经相对较好地实现了这一点,我确信微软有能力为.NET做同样的事情。但问题仍然存在:为什么会这样?

退出字节码类型的虚拟机,您还可以使用VMWare,Virtual PC等,它们可以在硬件级虚拟处理器上运行代码。其中一些需要相同的处理器,其他的(如VirtualBox和Bochs,我相信)在不同的处理器上运行虚拟处理器。

我还没有看到主机和虚拟环境之间的无缝集成。 VMWare在两者之间的拖放是可以的,但是能够在x86之上托管SPARC环境并且基本上让SPARC应用程序看起来与x86完全相同会更好(类似于Cygwin的X-windows基于Windows的常规应用程序。

答案 4 :(得分:3)

问题始终是你得到一个低于标准的应用程序。

如果某个应用程序需要在所有平台上运行,那么您最终会得到一个不能正确适应任何平台的GUI,以及一个错过平台上预期功能的应用程序 即仅存在于一个平台上的功能 - 在OS X上,您可以期望与所有最新功能集成,而且适用于Windows和* nix

我猜你最接近的是将核心功能跨平台,然后在顶层构建GUI和任何其他特定于平台的功能。

答案 5 :(得分:2)

正如其他人已经提到的那样,它是可能的(特别是基于JVM的语言和Python),很多人确实创建了跨平台的应用程序。令我惊讶的是坚持使用平台相关框架的人数。显然他们的销售情况更好。

这些与政治问题有关,而与技术问题有关。在实践中,跨平台开发最苛刻的技术问题来自低级硬件通信(驱动程序到特定设备等),但典型的应用程序无需直接与硬件通信。

答案 6 :(得分:1)

Microsoft仅在Windows上实现了.NET。因此,要在其他平台上运行.NET应用程序,需要新的实现。 Mono正在采取措施使这成为可能。当前版本运行大多数.NET 2.0程序集并支持许多Windows特定的接口。

至于你的其余问题:重新实现其他人使用的所有API都很难,现有项目也不完整。 Wine支持大多数Windows应用程序,但仅限于此。 GNUstep实现了大部分的OpenStep规范,并且与Mac OS的Cocoa API具有一定的兼容性,但它很不完整,并且会持续很长时间。

如果每个人都使用一个标准API,那么它可能会有所不同。但是,坦率地说,所有存在的API都会以某种方式吮吸。

答案 7 :(得分:1)

  

为什么通过.NET窗口这么难   应用到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平台

答案 8 :(得分:-1)

你可以使用Silverlight。至于Silverlight是否从浏览器迁移到本机应用程序,这是微软的政治决定,而不是技术问题。 Mono们也已经完成了.net来构建iPhone二进制文件的工作,所以毫无疑问,未来将会有更多的跨平台。

Adob​​e Air,Java和其他类似的东西也会制作跨平台的客户端应用程序 - 如果你真的想要,你甚至可以用C ++实现跨平台: - )