代码之家 › 专栏 › 技术社区 › John Thomas

跨平台开发-Delphi 2011:如何跨平台制作Windows绑定库?

cross-platform delphi

John Thomas · 技术社区 · 16 年前

您可能已经知道,Delphi的下一个版本很可能是 cross-platform .还有,这里有一些 polls 关于这件事。

虽然编写一个交叉编译器并不是我们现在非常感兴趣的事情,但移植一个与Windows绑定到多个平台的库肯定会引起我们的兴趣。

例如,你可以在VCL(Delphi的标准库)上思考。虽然它只是为Windows设计的,但它有其价值,当然,依赖它的还有巨大的代码库。

问题是: 哪种方法是使应用程序/库跨平台感知的最佳方法确保

我再次强调,我们对跨平台开发的最佳方式不感兴趣只有 (关于这个主题有一些问题)。我们还对另一项要求感兴趣: 旧的代码库/安装管理。

PS:来自其他语言(如C/C++)类似情况的经验和/或方法,这些语言被视为 标准做法 欢迎光临。

提前谢谢。

11 回复 | 直到 16 年前

T.J. Crowder 16 年前

可视化组件开发人员的视角:

向代码中添加功能级别,以便能够在不更改组件“核心”的情况下添加另一个平台。编译器有望有一个平台切换。(最好不止一个,相互配合工作。例如Windows/ARM、Windows/386、OSX/Cacao/386、Linux/Gnome/386)。

布局结构可能是这样的。

组件j。pas
Linux\ComponentJ。pas
Linux\Gnome\ComponentJ。pas
Linux\KDE\ComponentJ。pas
OSX\ComponentJ。pas
386\ComponentJ。pas
ARM\ComponentJ。pas

作为一名应用程序开发人员:

首先,我将把代码中的所有WIN API调用移动到Windows目录中的一组库中,以便能够在库级别对其进行IFDEF,并在编译器可用时将其转换为我希望支持的另一个平台,但只有在遇到它们时才可以。) 这也增加了为新平台添加适配器的可能性。在任何情况下,将可能的依赖项移到中心位置都是一种良好的做法。

user160694 user160694 16 年前

依我看,你无法构建一个xplatform Delphi并确保当前VCL应用程序的平稳过渡。这行不通。VCL(幸运的是,因为它允许伟大的应用程序)是在考虑Windows的情况下设计的,而试图设计一个在不同平台上工作的兼容库只会意味着更长的开发周期和许多妥协。结果将是一个无人愿意使用的图书馆。看看VCL发生了什么。NET:这是一个错误的选择。它在同一个操作系统上工作!

我们知道,针对非Windows平台 出生地的 应用程序需要一个本地GUI库。我们不在乎从头开始创建GUI,对于我们的应用程序来说,这是一条必经之路,我们不需要Windows GUI及其在不同操作系统下的所有标准,使用不同的标准——我们需要能够为目标操作系统编写一个完全本机的GUI。其他应用程序可能会通过GUI移植存活下来,但从长远来看,你不会得到一个真正的xplatform工具——你会得到一个可以为其他平台编译的工具,但会将一个平台范例带到其他平台——而且它也不会受到其他平台上“本地”开发人员的欢迎。如果你是Linux或Mac开发人员,为什么要学习如何使用一个将Windows继承到你的平台的库?如果Embarcadero想在实际开发人员之外销售XDelphi,它必须提供远不止一个新的CLX。

Wouter van Nifterick Andrey 16 年前

我将借鉴一些古老的经验,使windows和dos(Delphi 1/Turbo Pascal 7)之间的代码库可以交叉编译。经验法则是将代码分成多个单元。尝试在不使用窗口、消息或任何可视组件的情况下编写代码。如果您发现需要对其中一个进行调用,那么将该调用放在另一个单元中,并编写一个代理(您从中派生的抽象类工作得很好)来通过它分派调用。当发布了一个交叉兼容的版本时,您需要做的就是为代理的另一端编写新目标的代码。

如果你正在设计一个基于表单的系统,那么尽量多地使用标准组件。不要在事件中直接实现任何“业务”规则,而是将它们放在另一个单元中,并调用另一个单元来执行逻辑。

现在,为了让最终的项目交叉兼容,肯定需要进行一些更改,但是通过遵循这些简单的模式,您应该能够大大减少所需的工作量。

mj2008 16 年前

迄今为止的经验表明,让Delphi应用程序与未来版本兼容的最佳方法是坚持使用纯Delphi组件,不使用任何第三方组件。这样的应用可能会很糟糕,但在我看来就是这样。我使用了很多第三方组件,这些应用程序很棒,也很成功。但是,他们走向未来的可能性也不确定,这可能会导致这样的变化出现问题,但我宁愿现在有一个好的应用程序并有问题,也不愿现在有一个糟糕的应用程序而不需要担心它。

cybercake 16 年前

为了使VCL与Linux和Mac兼容,不应该做太多妥协。Windows是VCL的根。我更喜欢一个新的、非常干净的GUI框架,即使没有任何向后兼容性。让VCL越来越胖不是个好主意!

Wouter van Nifterick Andrey 16 年前

制作一个跨平台的Pascal编译器
做一个跨平台的RTL
把QT放在上面

好吧,看看 freepascal 和 lazarus

annlinux 16 年前

我不明白。全部的NET在我看来是一样的,只要我们不使用任何第三方。使用标准控件的Delphi已经功能齐全了,但你的应用程序看起来就像成千上万的人一样。

我认为Embar应该选择PDA、IPhone和安卓,因为Windows桌面已经在大肆扩张 98%的市场份额。

Mac电脑很贵,而Linux则一点也不贵。Mac和Linux没有用。不值投资。

John Thomas 16 年前

好吧,撇开这些话不谈——谢谢大家——我确实认为我们需要一些 附加的 东西:

我们需要工具来进行必要的转换
我们需要工具来帮助我们针对(某种形式的)MVC模式进行编程

Gad D Lord 16 年前

只需选择最新的4.6QT,并在Pascal和QT库之间添加良好的集成。他们以前做过(在Kylix时报)。如今QT功能非常强大。

我相信QT甚至比VCL更好,更新和修复的频率至少是VCL的10倍。

所以计划很简单:

制作一个跨平台的Pascal编译器
做一个跨平台的RTL
把QT放在上面

在所有平台上,您都将拥有一流的本地应用程序。

deksden 16 年前

我的意见是:

制作跨平台编译器(OS x/Linux/embedded solutions?/symbian?)。也许可以添加将pascal代码编译/转换为可移植c/c++代码的功能,以便在嵌入式平台上构建。
RTL必须分为跨平台层和本机层(与JCL一样)。
为跨平台兼容性添加新的核心组件,并为每个受支持的平台添加本机组件(QT for ex)
添加翻译实用程序以在平台组件之间创建/转换,例如:将纯windows窗体转换为mac os x cocoa窗体。
所有windows组件层次结构只需升级到支持x64,并具有最大的向后兼容性。所有跨平台组件必须处于并行层次结构中。
跨平台解决方案的下一个版本可以重构,并且可以包括迁移/转换实用程序。由于跨平台解决方案的代码库最少,跨平台解决方案的层次结构和类可以在不同版本之间进行重大更改,以实现最佳体系结构。

对不起,我的英语不是母语(俄语)!

-1

NeNo 16 年前

制作面向OSX/Linux的C/C++/Delphi编译器
制作可增强的C/C++编译器
编写新的VCL演示基金会(类似VGScene/WPF) 它不应该向后兼容!Delphi IDE应该是用这种VCL-PF编写
组件库应该保持原样(但有改进的数据绑定)
仅为Win64提供VCL 64位

这是个问题吗?