也许你已经知道了，下一个 Delphi 版本很可能会 跨平台。同时，这里有一些调查。
尽管编写跨编译器并不是我们现在非常感兴趣的事情，但将一个与 Windows 相关的库移植到多个平台肯定是令人感兴趣的。
例如，您可以考虑 VCL（Delphi 的标准库）。虽然它只是为 Windows 设计的，但它具有很大的价值，当然还有许多依赖于它的巨大代码库。
问题是：如何才能最好地让应用程序 / 库具备跨平台意识，并确保平稳的转换/升级路径（当然尽可能）？
我再次强调，我们不仅仅对如何进行跨平台开发感兴趣（这个主题已经有相关问题了）。我们还对另一个要求感兴趣：旧代码库/安装程序管理。
附：欢迎分享使用其他编程语言（例如 C/C++）的类似情况的经验和/或方法论，这些被认为是标准做法。
提前致谢。
从视觉组件开发者的角度来看：
在您的代码中添加功能级别，以便能够添加另一个平台而不更改组件的“核心”。编译器希望会有一个平台切换。（最好有多个，相互配合使用。例如：Windows/ARM、Windows/386、OSX/Cacao/386、Linux/Gnome/386）。
布局结构可能如下所示：
作为应用程序开发者：
我将首先将我的代码中所有的WIN API调用移入到一个Windows目录下的一组库中，以便可以在库级别进行IFDEF，并在编译器可用时将其转换为我想要支持的另一个平台，但仅在我遇到它们时才这样做。这也会更容易地为新平台添加适配器。无论如何，将可能的依赖项移至中心位置都是一个好习惯。
在我看来，你不能构建一个跨平台的Delphi并确保对当前VCL应用程序的平滑过渡。这是行不通的。VCL是为Windows设计的（幸运的是，因为它允许创建出色的应用程序），尝试设计一个兼容不同平台的库只会意味着更长的开发周期和很多妥协。结果将是一个没有人愿意使用的库。看看VCL.NET的情况：那是错误的选择。而且它在同一个操作系统上运行了！
我们知道，针对非Windows平台进行本地应用程序的定位需要本地GUI库。我们不关心从头开始创建GUI，对于我们的应用程序来说，这是正确的方式，我们不需要使用不同标准下的Windows GUI，在其他平台上编码完全本地化的GUI是必要的。 其他应用程序可能可以经受住GUI移植的考验，但从长远来看，你得到的并不是真正的跨平台工具-你获得的是一个可能可以编译到其他平台的工具，但会将一个平台范例带到其他平台上- 这也不会受到其他平台上“本地”开发人员的欢迎。如果你是一个Linux或Mac开发人员，为什么要学习如何使用一个带有Windows遗产的库来处理你的平台？你会觉得这很烦人。如果Embarcadero想在现有的开发人员基础之外销售XDelphi，它必须提供比一个新的CLX更多的东西。
如果您正在设计基于表单的系统，请尽可能使用尽可能多的标准组件。永远不要直接在事件中实现任何“业务”规则，而是将它们放在另一个单元中，并调用其他单元执行逻辑。
现在，肯定需要进行更改以使最终项目跨平台兼容，但是通过遵循这些简单的模式，您应该能够大大减少所需工作量。
在使VCL与Linux和Mac兼容时不应做出太多妥协。Windows是VCL的根源。我更喜欢一个新的、非常干净的GUI框架，即使没有任何向后兼容性。让VCL变得越来越臃肿并不是一个好主意！
我不太明白。只要我们不使用第三方，所有的.NET看起来对我来说都是一样的。 使用标准控件的Delphi已经完全具备功能，但你的应用程序会看起来像成千上万其他人的应用程序。
我认为Embar应该针对PDA、iPhone和Android进行开发，因为Windows桌面已经占据了市场的约98%。
Mac很昂贵，Linux则完全没有成本。去投资Mac和Linux没有意义，不值得这么做。
我的观点：
对不起我的英语不是母语（俄语是）！
除了之前说的事情，谢谢大家。我认为我们还需要一些额外的东西：
只需选择最新的4.6 QT版本，并在Pascal和QT库之间添加良好的集成即可。
他们以前做过（在Kylix时代）。如今，QT非常强大。
我相信QT甚至比VCL更好，至少更新和修复频率高出10倍。
所以计划很简单：
这样，您就可以在所有平台上拥有一流的本地化应用程序。
