为什么这么难创建64位Delphi？

Question

互联网上满是要求64位Delphi的开发人员，以及要求64位版本的Delphi软件用户。

• delphi 32bit：1.470.000页
• delphi 64bit：2.540.000页： - ）

这就是为什么我一直想知道为什么Embarcadero仍然不提供这样的版本。

如果这很容易，我相信它已经很久以前就已经完成了。那么Embarcedero需要克服的技术困难到底是什么？

• 是编译器，RTL / VCL还是IDE / Debugger？
• 为什么32位到64位的切换比Borland从16位切换到32位更复杂？
• FPC团队在添加64位支持时是否面临类似的问题？
• 当我认为创建64位Delphi应该比Kylix或Delphi.Net更容易时，我是否在监督重要的事情？

Answer 1

对于我在论坛中阅读的内容，我认为主要的延迟是32位的编译器根本不能轻易地适应64位，所以他们必须编写一个新的编译器，其结构允许移植它很容易到新的平台。在该领域，这种延迟很容易理解。

新编译器必须要做的第一件事就是支持当前的32位Windows，然后再将其作为64位目标，以便更容易理解延迟。

现在，在通向64位支持的道路上，Embarcadero决定以32位MacOSx为目标，这个决定是有些人根本不理解的。就我个人而言，我认为对于Embarcadero的业务观点来说这是一个很好的营销决策（等等，我不是说64位支持不那么重要，请仔细阅读，我不是在谈论重要性，而是关于商业性）。在64位的道路上这是一个非常有争议的额外延迟（除了Embarcadero说他们有并行工作的团队，事实上有一个延迟，至少对版本问题 - 再次营销 - ）。

考虑到FPC不是商业产品也很好，因此他们可以比Delphi更容易添加/删除功能。

Answer 2

如果不是因为shell扩展的限制（我有一个加载到Windows资源管理器中），我可能永远不会关心64.但由于这个限制，我需要它，我现在需要它。所以我可能不得不在Free Pascal中开发那个部分。遗憾的是，除此之外，很少有应用实际上会从64中受益。国际海事组织，大多数用户要么正在喝冷却剂，要么因为被欺骗购买听起来很棒的东西而变得头疼。我认识一个很高兴运行Win7 / 64的人，所以他有足够的内存来运行VM中的完整拷贝的XP，如果他像我告诉他的那样得到Win7 / 32，他就不需要。 ： - ＆LT;
我认为每个人都被硬件制造商欺骗了，特别是RAM经销商本来会有一个非常软的市场 无论如何，回到手头的问题......我被夹在岩石和坚硬的地方之间。由于M $的架构决策（不允许在Windows资源管理器中使用32位DLL）和感知问题（64位必须是32位，或者32位必须在32位上运行），我的客户对我提出了要求。 “惩罚核心”或其他东西）。因此，我受到了很大程度上“人为”的动机的驱使。因此，我必须将其投射到Embarcadero上。但最终，在Delphi中对64位支持的需求是IMO，主要基于BS。但他们将不得不回应它，我也一样。

Answer 3

我想，我从Embarcadero的观点中对你的问题的“回答”最接近，这篇文章在Nick Hodges的future of the Delphi compiler文章中进行了总结。

Answer 4

真正的问题不是技术问题。首先是Borland / CodeGear，然后是Embarcadero，表明他们不喜欢保留多个Windows版本的Delphi。他们推迟了Unicode切换，直到他们完全放弃Ansi OS支持。实际上，他们需要支持两个一个Win32编译器/库和一个64位编译器/库，因为使用了32位和64位Windows操作系统。我相信他们正试图尽可能地延迟它，以避免尽可能多地保留32位的。 Delphi编译器变得非常古老而且难以理解，但他们决定以非Windows操作系统为目标重写它，我确信驱动程序是将一些Embarcadero数据库工具移植到非Windows 32位平台，忽略了Delphi客户的实际需求并且在跨平台尝试中再次延迟64位编译器和库再次尝试偷工减料以快速交付，从而注定再次失败。 顽固地说，他们不想转换到两年的发布周期，因为他们每年都想要新的现金，尽管在如此短的周期内发布真正做得好的改进变得越来越困难 - 并且用了将近四年的时间来修复引入的问题Delphi 2005的变化。反过来，他们必须让开发人员努力引入“次要”改进来证明升级的合理性，而不是完全处理64位内容。

Answer 5

我听说他们想要完全重写编译器而不会失去向后兼容性。考虑到没有语言的完整语法描述（我已经问过，但他们没有，所以我自己可以向公众提供）。我可以想象，文档并不像他们想要的那样完整。所以他们可能正试图对自己的代码进行逆向工程。

我是Delphi的坚定支持者，我认为2009年和2010年都是很棒的版本（与坚如磐石的＃7相比）。但缺乏64位支持最终会杀死他们。

回到问题，最大的问题应该是编译器。从16位到32位的转换更容易，因为遗留的更少（delphi 2是32位，而Object Pascal语言比现在简单得多）。 我不确定Free pascal。也许他们的代码很容易移植。也许他们失去了一些向后兼容性当然，你可以问他们。

Answer 6

我知道你在询问技术问题，但我认为市场营销部门可能是最大的问题......我相信他们会因新市场的前景而变得更加兴奋，这些新市场带来了新客户，从而设法改变优先顺序。一个问题（在我看来）是糟糕的跟踪记录：我们过去看过kylix和delphi.net都是ehm kylixed。我可以想象新客户会等待，看看它是否会留下来，反过来可能会让embarcadero过早地离开它。

那说：x64肯定存在一些问题和设计考虑因素，我希望Embarcadero团队能够分享它对它们的看法并与社区讨论（以防止我们对unicode更改的咆哮）。

Answer 7

已有64位Delphi（Object Pascal）。它被称为Free Pascal。因此，虽然我毫不怀疑它很难，但它并不“太难”，以至于它不可行。当然，我不能推测Embarcedero。

Answer 8

来自Embarcadero的Allen Bauer最近也表示他们必须完全不同地为64位实现异常支持“由于Win64异常ABI的差异”。