对于那些想要从 Delphi 7（及以下）升级到 Delphi 2010 的人有什么提示吗？

Question

我有兴趣重新评估 Delphi 2010。主要问题似乎是 ascii 到 unicode 的转换。 您发现任何有用的提示或资源？

非常感谢。

---

编辑：

在这一点上，我对那些想要升级的人的建议是：

http://www.embarcadero.com/images/dm/technical-papers/delphi-in-a-unicode-world-updated.pdf
WideString 是否与 Delphi 2009 中的 String 相同
Delphi 2010 的编译器版本是什么？
http://chee-yang.blogspot.com/2008/10/delphi-2009-unicode.html

GIF 问题：
请注意，Gif（由 Melander）和 Png（由 Martijn Saly？）图像现在已合并到 Delphi 2010 中。您必须使用条件才能使用正确的 GIF 单元：

USES Windows, SysUtils, Graphics, blabla
{$IFDEF VER150}
  , GIFImage,     {Delphi 7}
{$ELSE}  
  GIFImg          {Delphi 2010}
{$ENDIF}; 

您还需要“修复” Embarcadero 提供的 PNG：http: //talkdelphi.blogspot.com/2009_03_01_archive.html

您需要知道的其他事项是，在 Delphi 2010 中打开项目之前，您确实必须备份您的项目。即使您不按保存按钮，Delphi 2010 也会更改您的 DFM 文件。 表单将丢失数据，并且不会在 D7 中编译。

---

更新德尔福 XE

我终于购买了 Delphi XE。 Delphi XE 提出了一些新特性，但不幸的是，其中很少有根本不起作用（后台编译、UML 建模、代码洞察力等）。 其他功能已降级（例如，帮助和）。
IDE 也不像 Delphi 7 那样稳定和快速，并且工具栏有实际问题（最好不要自定义 IDE）。 还有一个令人讨厌的错误，即 IDE 的 CPU 利用率为 100%（有关所有这些问题，请参阅我的其他帖子）。 我希望在更新 2 和 3 中他们将解决一些最严格的问题。

无论如何，我认为我升级得太早了，因为现在 Embarcadero 宣布了 64 位编译器，所以我可能不得不再次支付很多钱来升级到下一个版本的 Delphi 以获得该编译器。 对于那些仍在考虑升级到 Delphi XE 的人，我建议您试用 Delphi XE HEAVILY。 结论：

• Delphi XE 带来了很多新功能，但显然您不会使用所有这些功能。
• IDE的稳定性也好不到哪里去。
• 它可以帮助您构建更多最新的应用程序（现代 UI 打开/保存对话框、应用程序清单）。
• 支持unicode。

---

更新德尔福 XE7

XE 和 XE7 之间的差异并不像从 Delphi 7 升级到 XE 那样大。 IDE 和以前一样稳定（RTL 中有很多崩溃和随机访问违规）。

---

更新德尔福里约

考虑到自上次更新以来的多年时间，我可以肯定地说 XE7 和 Rio 之间的差异几乎看不到——除了那些对跨平台应用程序（Mac、Android 但不是 Linux！）感兴趣的人。

优点

• 真正的高 DPI 支持（真的是 Embarcadero？经过这么多年？）。
• IDE 不会像以前在 XE7 中那样经常崩溃。
• VCL 主题终于（似乎）起作用了。
• 迄今为止最稳定的 IDE（如果您打开一个包含多个项目的项目组，仍然会崩溃）。
• 几乎完整的跨平台支持（您需要购买更昂贵的 Architect 版本才能获得 Linux）。 幸运的是，对我来说，这有点太晚了。 我需要跨平台的项目已经在 Lazarus 下启动了。
• 升级代码非常简单。

缺点

• 一些高度宣传的功能，如黑暗主题，根本不起作用！
• Insight 仍然有问题：IDE 不支持新的语言特性（如声明内联变量）（代码将有摆动的下划线红线）。 这个问题可能永远不会得到解决。
• 另一个超级烦人的 IDE 问题是，即使在您修复它们之后，编译器仍会显示最后的提示/警告/错误。 看起来日志数据保留在某种缓存中。

总的来说，它是迄今为止最稳定的 IDE，但我仍然想知道（尤其是与 Lazarus 相比）是否值得这么多钱。

---

多年总结：
Delphi 是一门漂亮而干净的语言。 Delphi 编译器的速度使任何C++ 编译器看起来都像是孩子们的玩具。
当我说我是 Delphi 开发人员时，我仍然感到羞耻。 Delphi 作为一种语言现在已经灭绝。 只需在德国寻找 Delphi 工作，仅列出74 个职位（但其中大多数与 C# 和其他混合）。 C++ 有超过 1500 个职位！ Borland 和 Embarcadero 帮助了很多人杀死 Pascal。 他们现在确实提供了一个免费的（即使是残废的）Delphi 版本，但损害已经造成。 现在复活Delphi为时已晚。

我认为导致这种状态的三个主要问题：

1. Borland 放弃了 Delphi（与其他语言相比，Delphi 落后了）。
2. Embarcadero 接管了客户，但不尊重客户（错误过多、价格过高的产品）。
3. 主要问题：多年来（根本没有）推广该语言。 没有理智的公司会花费数千美元来获得一种已经垂死的语言的许可证。 并且缺乏免费许可证完全排斥新一代的程序员。

因此，我们在 StackOverflow 上，每年都在想是否值得投资新的 Delphi 许可证。

更新
最后，Emba 发布了一个免费（又名社区）版本，你可以看到效果。
多年来第一次，我不觉得羞于公开说我是 Delphi（一种垂死的语言）的用户。

Answer 1

我们专门为这个问题创建了一个网页：

http://www.embarcadero.com/rad-in-action/migration-upgrade-center

在那里，您可以找到涵盖迁移问题的网页、文档、网络研讨会重播等。

人们说的第一句话是“我有一个庞大的代码库，迁移到 Unicode 将需要永远”，几乎无一例外，他们发现“永远”确实比他们最初想象的要短得多，而且 Delphi 的新功能2010让这一切都值得。

Answer 2

最大的问题在于 3rd-party 库和 VCL。 如果他们不在 D2010 上，那可能会很痛苦。 如果您使用字符串或 PChar 数组的长度进行计算，假设每个字符一个字节，就会出现 Unicode 问题。 您通常可以将所有内容都视为旧式 AnsiString / AnsiChar。 但是你并没有得到 Unicode 的好处。 如果您没有任何在 Unicode 中难以做到的事情，只需在 Unicode 中做所有事情，与您必须担心来回切换相比，您将走得更远。

Answer 3

只要您没有对字符串做任何“有趣”的事情，将代码转换为 unicode 本身并不需要太多时间。 我在不到 2 周的时间内转换了近 100 万行代码 + 数据库。 codegear 的伙计们做得非常好，做得更简单。

您的代码可能会在 D2010 中重新编译而无需任何更改（但有很多提示/警告）。

转换中最严重的问题来自对 Window API 的调用不正确。 例如，函数 GetComputerName 会询问您 TChars 中缓冲区的大小（由 API 指定）。 在 Ansi 中，TChar = 1 字节，所以 Length = SizeOf。 在 Unicode 中，它不再是真的了。 更糟糕的是，对 API 的调用可能不会失败。 它只会覆盖内存的一些有效部分，并且会在很久以后崩溃。

哦... Windows API 中的 Ansi 和 Unicode 之间也存在细微差别。 例如，CreateProcess 的lpCommandLine在 Ansi 版本中是只读的，但在 unicode 版本中是读/写的。 因此，使用常量作为参数在 Ansi 中运行良好，但在 Unicode 中的 Kernel32.dll 中会崩溃。

总的来说，这在很大程度上取决于您正在使用的代码的质量。 错误的代码可能很难移植到 D2010。 好的代码应该很容易。

并阅读 Nick Hodges 链接到的资源，它们非常有帮助。

Answer 4

对于 Unicode 转换问题，查看人们遇到的问题和其他人所做的最佳选择是获取Cary Jenson 的白皮书：Delphi Unicode Migration for Mere Mortals 。

此外，我强烈推荐Marco Cantu 的“Delphi 2009 手册” ，它描述了 2009 年主要版本中的所有更改，包括 Unicode 和泛型等。 他那本书中的大部分 Unicode 材料都在他的白皮书：Delphi 和 Unicode中。

Answer 5

我们已经从 Delphi 7 升级到 Delphi 2007、2009 和现在的 2010！ 以下是我们发现的最大问题。

• 线程已更改，不推荐使用 Resume 和 Suspend。
• 统一码
• 项目结构已更改且不向后兼容
• dfms 的结构发生了变化，不向后兼容

希望这可以帮助。

Answer 6

我同意 Chris 的观点 - 将我们的代码迁移到 2010 的最大问题是让所有 3rd 方库正常工作。 其中一些需要在这里和那里进行少量的源代码编辑，并且必须从修改后的源代码中安装。 尽管如此，这表示解决问题还不到一天左右的时间。

我们在 2010 年遇到的唯一另一个问题是一小段代码由于 2010 年 ProcessMessages 工作方式的改变而出现错误。 这是一段旧代码，可能不应该按照最初的方式编写（ProcessMessages 和 Sleep() 在 while 循环中等待 OPC 变量更改）。 它在 2007 年工作，但在 2010 年它以某种方式吞噬了系统消息并锁定了 OPC 服务器。 对我们来说，这是一个小问题，但正如 Ken 所说，这可能取决于您移植的代码质量。 2010 年似乎对糟糕的实践和丑陋的黑客行为不太宽容。

Answer 7

查看此 Embarcadero 网络研讨会，了解如何从旧版本的 Delphi 迁移，其中包含一些关于寻找什么以及如何更新代码（包括在此过程中为您提供帮助的工具和资源）的故事： https://community。 embarcadero.com/blogs/entry/migrating-delphi-case-studies