4

Which tool/approach would you suggest to convert of a large 16bit Windows GUI application, written in old Borland Pascal 7 / OWL, to Delphi?

Understanding the pretty heavy differences between OWL and VCL, as well as the differences between the pointer manipulations in 16bit pascal and the state-of-art using of strings and objects in Delphi - are there any ways/tools which could help to avoid almost complete rewrite of the application?

4

5 回答 5

2

我认为您需要确定;

a) 有多少代码与业务逻辑、数据(库)操作以及专有文件结构、数学处理等有关?这可能会在很大程度上“按原样”提升,因为它更有可能用 OWL/BP7 的更小、更明显的元素以“pascal”编写。例如,当我使用应用程序执行此操作时,我有一系列单元处理加载/保存专有文件、计算复活节的东西、对数组进行数学运算的东西等等——所有这些东西都从 BP7 到 Delphi (1)几乎没有变化。

b) 有多少代码与 GUI 相关(仅此而已) - 消息循环处理程序、对话框元素构造函数、控件属性等。这些东西需要大量工作才能移植到 Delphi,除非你能找到某人在 .RES->.DFM (或类似的)中有一条很好的线,我想你会考虑从头开始构建这个位。没有坏事,因为如果它是一个 16 位 Windows 应用程序,那么您可能希望借此机会至少让它看起来更“现代”一点。我认为这将是该项目中劳动力最密集的部分。

c) 有多少代码正在使用您知道在 Delphi 中可以以不同方式完成的东西,但现在它可以在 pascal 中工作?这就是@BloodySmartie 关于迁移到旧版本的 Delphi 的观点对我来说有意义的地方。您应该能够将该项目移植到诸如 Delphi 5/7 之类的东西上,从而对字符串操作之类的东西进行明显(并且易于理解)的更改。在我看来,你可以留下的这些东西越多,就越好。获取可以运行并检查基本行为的东西,然后在资源允许的情况下开始重构/改进以充分利用 Delphi。你可能(和我一样)在 BP7 中有指针数组,每个指针指向一个指针数组,最终指向一个对象——这就是我们在 16 位 Windows 世界中解决内存限制的方法。当我第一次移植我的应用程序时,这些指向指针数组的指针数组在 Delphi 中仍然可以正常工作,我不理会它们,直到我有时间对这些结构做一些更“类似 Delphi”的事情。

但在你做所有这些之前 - 你为什么要移植应用程序?如果您要移植它是因为无论如何您都要对应用程序的功能进行合理数量的更改,那么现在可能是重写应用程序的正确时机。当您在 Delphi 中重写时,您仍然可以使用基于业务规则的大量函数和过程,因此它不一定是从头开始的完整和完全重写。

于 2009-02-04T13:21:17.933 回答
1

I guess there is no tool to support your migration but i'd try to start in an old Delphi Version like 1,2 or 3. This syntax should be much nearer on BP7 than the syntax of newer Delphi Versions.

At this time, you should first try to just bring your app logic to delphi, without any visual stuff. Then use the form designer to rebuild your GUI.

A important point you should pay attention to is that a DOS string is an ASCII-String, while the Delphi strings up to Delphi 2007 are ANSI-encoded. In Delphi 2009, the string keyword describes a unicode string.

于 2009-02-04T11:49:58.290 回答
1

很久以前,当我将 OWL 换成 VCL(在 C++ 中)时,从头开始编写一切变得更加容易。可能有一些代码部分不处理用户界面和字符串操作,但除此之外它完全不同。

事实上,我最大的应用程序之一仍在 OWL 中,因为我只是懒得重写它。只要它有效,就让它吧。

于 2009-02-04T12:00:05.010 回答
1

我们也有 - 并且仍然有 - 大量的 owl 应用程序。所以我们确实将 16 位 owl 移植到 32 位 owl,因此仍在开发和维护我们基于 owl 的应用程序(实际上是使用 Delphi 2007 for win32)。

您可能会发现这种方式比切换到 vcl 更容易、更快捷。

欢呼安德烈

于 2009-09-16T13:46:29.780 回答
0

FrameworkPascal.com 提供了一个有效的解决方案,只需对原始 Windows 3.1 代码进行少量更改。我们做了一段时间,但现在我们提供了一个带有 32 位兼容 OWL 单元的完整解决方案。我们还提供 ODBC SQL 单元、基于 MAC 地址的安全技术和类似 CRT 的特殊单元,这些单元可以处理为 DOS 文本和图形模式模式编写的代码、混合和新的 32 位图形,并针对 Windows 32/64 GUI 应用程序. 可以使用 OWL Windows MDI 编译的遗留代码从可以快速修改的模型应用程序演示开始。

于 2010-07-21T12:32:08.543 回答