如何解释为所有操作系统编写通用的跨平台C ++代码并交付产品并不是那么容易？

我们公司为Windows发行了一系列桌面产品，许多Linux用户在论坛上抱怨我们应该是几年前为Linux编写的产品版本，而我们不这样做的原因是

• 我们是一家贪婪的公司
• 我们所有的技术专家都是白痴

我们的平均产品约为300万行C ++代码。

我和我的同事的分析如下：

• 编写跨平台的C ++代码并不是那么容易
• 准备大量分发包并为所有广泛的Linux版本维护它们需要时间
• 我们的估计是Linux市场占所有用户的5-15％，而这些用户可能不想为我们的努力付出代价

当提出这个问题时，人们的回答再次是，我们是贪婪的不合格白痴，而当一切都做对了时，这一切都是简单而轻松的。

我们对编写跨平台代码和维护大量分发包需要付出大量努力这一事实的评估有多合理？我们在哪里可以找到一些简单而详细的现实故事分析，这些分析显示出毫无疑问的阴影，确切地需要付出多少努力？

请记住，大多数人都是员工，因此不会生活在他们需要关心获利的世界中。他们出现在工作中，去做自己的事情然后回家，却从未真正考虑过整个过程的工作方式。尽管很聪明，但许多技术人员对业务却一无所知，并且经常被教条所蒙蔽。

没错，当然，制作如此规模的x平台软件并非易事。特别是当您没有一家拥有数十个开发人员和数百万用户的公司时。而且它不仅是技术限制。一切都是关于成本与收益。是的，您可能需要在明年将其移植到Linux（尽管您已经注意到，它已经可以在WINE中运行）。当然，那一年的开发时间并不是免费的。最后，也许会净你另外5-15％的用户（根据您的估算）。或者，您可以花费相同的金钱/精力，将其作为新版本投入到Windows开发中，或者全部投入市场营销，并增加50％的用户群。哪个听起来很明智？（显然，这些数字需要根据您的公司进行定制，并且最终结果可能会有利于移植）。

我不知道这是否有助于说服“真正的信徒”，但这是明智的商业举措。而且，如果您不采取明智的业务行动，那么您将倒闭。然后肯定不会有Linux版本。

我认为这里有两件事要考虑：

首先，从某种意义上说，它们是正确的。如果您从一开始就计划跨平台C ++，那么编写它并不难。这几乎可以肯定是您所看到的问题。绝大多数开放源代码应用程序（Linux用户平均每天接触的大多数应用程序）都是跨平台的。考虑一下普通Linux用户每天用C或C ++编写的并与之交互的应用程序数量，这些应用程序不仅可以在Windows和Linux上运行，还可以在x86，x86-64，ARM，SPARC，MacOS，BSD，Solaris等操作系统上运行，等等。这部分是因为渴望从头开始移植代码以在其系统上运行的人们，而且还因为当时的惯例是为跨平台可移植性进行规划。

第二件事是，市场可能比您认为的更可行。有一个很大的误解，认为Linux上的人们不想为软件付费。对于某些人来说可能是对的，但是有很多人（大多数人，我认为）使用Linux，因为它对他们更有效，他们更喜欢Linux，而不是因为价格。另外，如果您的公司生产的产品主要用于专业环境，则公司很习惯为在Linux系统上运行的软件付费。

至于包装的要点，正如其他人所说，您实际上只需要为主要发行版的最新版本生产包装即可。实际上制作软件包并不十分困难，大多数主要发行版都使用debian软件包（debian，ubuntu等）或RPM（fedora，suse，centos，mandrake），因此修改某些脚本非常少要从基准.deb和基准.rpm生成多个软件包，对于其他所有人，只需将二进制文件和自述文件放到压缩包中，人们就会想出如何安装它。或者，您可以跳过所有打包，而只需使用bash或perl脚本发布单个tarball即可进行安装。

至于如何解决您论坛上抱怨的用户，正如Joe Internet所说的那样，他们可能只是无论如何都会抱怨的人们的百分比，但是我要做的第一件事就是尝试说明您拥有大量的遗留代码在设计时并未考虑跨平台支持。第二，老实说，看看是否会为建立Linux端口提供经济支持，并公开其结果。最后，如果端口在财务上不可行，请参见做一些工作以使该程序在WINE上正常运行。WINE不应是第一个解决方案，但它可能会使那些只想在Linux中使用您的应用程序的人感到安心，并且它是一个比完整端口便宜的项目。实际上，如果您将代码作为项目的一部分添加到WINE代码库中，则不仅可以打开自己的市场，

Adobe，是吗？

但是，认真地提供一些奖励，以便他们可以预购Linux版本。如果您有足够的订单使及时的港口变得值得，那么就退还这些款项，这样您便可以证明没有足够的人在意这个港口。

但是，如果您移植了一些东西，只需针对最新的Ubuntu LTS版本，RHEL，SLED并提供tar.gz，如果他们想使用其他东西，人们可以尝试开始工作。剩下的3个软件包让您担心，其他任何人都可能足够了解tar.gz版本。

编写跨平台的C ++代码并不是那么容易

恰恰相反。当您计划跨平台工作并为您使用的特定于平台的API提供抽象时，您的绝大多数代码已经是跨平台的。如果您已经在使用诸如Boost或Qt或NSPR之类的流行库，那么您已经非常接近可以正常工作的跨平台构建了。

在开发周期后期进行移植时，最常遇到的问题是，在程序的某些部分中，有相当一部分代码依赖于平台特定的API，它们不需要直接使用它们，也可能根本不需要使用它们。（一个好的设计将具有高度解耦的模块，并且可以随意替换重写的类替换成组的类。如果对于给定的模块不是这种情况，则这是强烈的代码味道。）

最简单的方法通常是编写一个“实用程序”类，然后将所有特定于平台的内容扔在那里。这并非“轻松而轻松”，但肯定比您想像的要难。

准备大量分发包并为所有广泛的Linux版本维护它们需要时间

这是一个不幸的误解。虽然维护多个平台的构建确实需要付出额外的努力（在设置专用的每日构建服务器并学习如何打包特定发行版的过程中），但并非需要为“大量发行版”维护它们]。” 恰恰相反。您只需要维护少量的软件包（例如，Ubuntu，Fedora和一个与LSB兼容的tarball），各种Linux社区将负责其余的工作。特别是如果您的软件很流行，HOWTO将在每次发行时出现，并提供所需的安装说明。或者，如果您的软件可以自由分发（即使它不是免费产品，也可以这样做）（如果您的许可允许），则更为流行的发行版将具有某种替代版本的存储库，其中包含您的软件副本。

社区通常对此非常好，如果您允许，经验丰富的用户会愿意为您完成很多此类工作。

我们的估计是Linux市场占所有用户的5-15％，而这些用户可能不想为我们的努力付出代价

另一个不幸的是，非常错误的误解。

仅仅因为Linux用户免费获得其操作系统并不意味着他们不愿意为软件付费。如果软件非常好并且有广泛的需求，与Windows用户相比，Linux用户通常会更愿意花钱。只需看一下Humble Indie Bundles，其中Linux用户平均为每个用户支付的费用是Windows用户的两倍。

与其他平台（在您不了解您的产品的情况下我们无法知道）相比，您的产品在Linux用户中的需求可能也更大（这取决于该领域中现有的软件类型）。您可能拥有比您意识到的更大的潜在市场。

有了这样的态度，我只会无视它们。它们听起来像X的片段，其中X可以是任何东西，无论您做什么都将抱怨。是否发布Linux版本，这是您的选择，而不是他们的选择。

如果您在Nvidia工作...

对于上帝的爱，吸干它并写一些不错的驱动程序。

否则，如果您正在执行常规业务应用程序，则将将来的项目定位为在C＃上运行。

Mono完全兼容.NET 3.5，甚至可以使用winforms GUI。您需要注意的唯一模块是特定于操作系统的模块，但它们之间相距甚远。