Linux和Windows之间的移植如何工作？

Question

如果某个特定的软件在一个平台上运行，而程序员/公司/任何想要将它移植到另一个平台上，究竟是做了什么？我的意思是，他们只是重写linux或Windows特定的引用到另一个的等价物？或者是否需要完整的重写？

只是试图理解是什么让它如此成本过高，以至于许多主要供应商都没有将他们的软件移植到Linux（特别是考虑Adobe）

由于

Answer 1

这是像qt或gtk这样的跨平台工具包的重点，它们提供了一个与平台无关的API，它委托编译程序的任何平台。

有些公司不使用这样的工具包，并自己编写（无论出于何种原因 - 很可能与优化相关），这意味着他们不能只为其他操作系统重新编译代码。

Answer 2

根据我的经验，将一个大型现有程序放在一个平台上并将其移植到另一个平台上的成本过高有三个主要原因：

1. 它（不一定是故意的）广泛使用了一些库或API（通常是GUI，但也有很多其他的东西），结果证明不存在于另一个平台上

2. 它在不知不觉中变得依赖于非标准功能或编译器或其他工具的奇怪之处

3. 它是由一个不知道你有使用一些古怪的功能来让其他平台工作的人写的（就像一个没有撒上的Linux库）使用正确的__declspec指令，您需要一个良好的Windows DLL。

如果您从一开始就考虑设计目标，那么编写跨平台应用程序要容易得多，而且我有三个具体建议：

• 使用Boost-oodles通常可以从特定于平台的API和库中获得的东西，但是通过使用Boost，您可以跨平台获得它。

• 使用跨平台库完成所有GUI编程。我最喜欢的是Qt，但也有其他有价值的。

• 在两个平台上构建并测试每天，永远不会为代码提供机会，只在一个平台上开发依赖关系并且发现它太晚了。

Answer 3

还有一些库可以轻松地（至少在特定区域）轻松调用Linux的Windows API。请参阅Windows to Linux porting library。

Answer 4

将应用程序移植到不同平台可能非常困难的原因有很多，通常是因为应用程序用来与系统通信的某些接口不可用，并且要么必须在其上实现它们。拥有，移植应用程序所依赖的库，或重写应用程序，以便它使用替代功能。今天的大多数语言在硬件架构和操作系统中都非常便携，但问题在于OS（或平台）提供的库，系统调用和可能的其他接口。更具体一点：

• 编译器的配置和它们提供的标准功能可能不同。在Windows上，最流行的C / C ++编译器是Visual Studio，而在unix上它是gcc和llvm（与标准库glibc或BSD libc结合使用）。他们期望不同的标志，不同形式的声明，产生可执行文件和共享库的不同文件格式。尽管C和C ++具有标准库，但它们在不同平台上的实现方式不同。有些系统的目的是使编译变得可移植，例如Autotools，CMake和SCons。

• 在标准库之上还有OS提供的附加功能。在Windows上，它们由win32 API覆盖，在unix系统上，这些是POSIX标准的一部分，具有各种GNU，BSD和Linux特定扩展，还有普通系统调用（应用程序和操作系统之间的最低级别接口） 。 POSIX功能在Windows上通过cygwin和mingw等系统提供，win32 API函数可通过Wine在unix上获得。问题是这些实现并不完整，并且通常存在轻微（但重要）的差异。

• 与桌面系统的通信（为了制作GUI界面）的方式不同。在Linux上，这可能是X Window系统（与freedesktop库一起）或Wayland，而Windows有自己的系统。有些GUI试图为这些提供抽象接口，例如Qt，GTK，wxWidgets，EFL。

• OS提供的其他服务，例如网络通信，可以不同方式实现。在Windows上，许多应用程序使用.NET库，对unix系统的支持有限。一些unix应用程序依赖于特定于Linux的功能，例如systemd，/ proc，KMS，cgroups，名称空间。即使在unix系统（Linux，BSD系统，Mac OS X，......）中，这也限制了可移植性。即使.NET库在不同版本之间也不是很兼容，它们可能在旧版本的Windows或嵌入式系统上不可用。 Android和iOS完全有不同的界面。

• Web应用程序通常是最便携的，但HTML5是实时标准，并且在某些浏览器/ Web引擎中可能还没有许多接口可用。这需要使用polyfills，但它通常比“原生”应用程序的情况要痛苦得多。

由于所有这些限制，移植可能是一项相当困难的工作，有时使用跨平台抽象库/平台（如Qt或更高版本）从头开始创建新应用程序更容易，特别是针对其他平台Java），或作为Web应用程序（可能捆绑在像Electron这样的东西）。从一开始就使用这些是个好主意，但是许多程序员选择不这样做，因为应用程序的外观和行为往往与平台上的“本机”应用程序不同，并且它们在交互方式上也可能更慢，更受限制与操作系统。

Answer 5

将一个尚未独立于平台的软件移植到一起可能是一项艰巨的任务。通常，代码与非可移植API根深蒂固，无论是第三方还是仅仅是OS库。如果第三方供应商没有为您正在移植的平台提供API，那么您几乎不得不完全重写该功能，或者找到另一个可移植的第三方。这只会非常昂贵。

最后，移植软件还意味着在另一个平台上支持它，这意味着雇用一些专家，并提供培训支持来回答更复杂的查询。

最后，这样的过程可能非常昂贵，而且额外的销售额很少。可悲的是，这个决定很容易：专注于您当前平台上的新功能，而您知道客户将要为此付出代价。

Answer 6

如果软件是针对单个操作系统编写的，则可能会进行重大返工。第一步是将所有特定于平台的代码绝对移动到代码库的单个区域中;这个区域应该很少或没有特定于应用程序的东西。然后为新的目标操作系统重写这个孤立的代码部分。

当然，这掩盖了一些非常重要的影响。例如，如果您的第一个版本针对Win32 API，那么任何GUI代码都将与Windows紧密相关，并且为了保持您的理智，您需要将所有代码移动到跨平台的GUI框架，如Qt或GTK。

Answer 7

在Mono下，您可以编写适用于两个平台的C＃Winforms程序。但为了实现这一点，Mono团队必须编写自己的Winforms库，它基本上复制了Winforms的所有功能。所以仍然没有免费的午餐。

Answer 8

大多数软件在某种程度上都是可移植的。对于C应用程序 - 除了路径更改等之外，该区域将有很多#ifdefs。

很少相同软件的windows / linux版本不共享公共代码库 - 这实际上意味着它们只共享一个通用名称。维护更多代码库总是比较困难，但我认为移植应用程序的实际问题与技术方面有很大关系，而与业务方面有很多关系。 Linux拥有的Windows / OSX用户要少得多，他们中的大多数人都希望一切都像啤酒一样免费，或者只是出于某种宗教习惯而讨厌商业软件。

当你想到它时 - 大多数开源软件都是多平台的，无论用什么语言来实现它。这说明了一切......

P.S。免责声明 - 我是自由和开源软件的狂热支持者，我不想侮辱任何人 - 我只是分享我对该主题的看法。