Wou*_*ick 21 delphi compiler-construction 64-bit
互联网上满是要求64位Delphi的开发人员,以及要求64个版本的Delphi软件用户.
这就是为什么我一直想知道为什么Embarcadero仍然不提供这样的版本.
如果它很容易做到,我相信它已经很久以前就已经完成了.那么Embarcedero需要克服的技术难题到底是什么？
som*_*one 13
对于我在论坛中阅读的内容,我认为主要的延迟是32位的编译器根本不能轻易地适应64位,因此他们不得不编写一个新的编译器,其结构允许将其移植到新的平台很容易.在该领域,这种延迟很容易理解.
新编译器必须做的第一件事就是支持当前的32位Windows,然后将其作为64位目标,这样才能更容易理解延迟.
现在,在通向64位支持的道路上,Embarcadero决定以32位MacOSx为目标,这个决定是有些人根本不理解的.就个人而言,我认为这对于Embarcadero商业观点来说是一个很好的营销决策(等等,我不是说64位支持不那么重要,仔细阅读,我不是在谈论重要性,而是关于商业性).这是一个非常有争议的额外延迟,通向64位(除了Embarcadero说,他们有团队并行工作,事实上有一个延迟,至少对版本问题 - 再次营销 - ).
同样值得注意的是FPC不是商业产品,因此他们可以比Delphi更容易地添加/删除功能.
如果它不是对shell扩展的限制(我有一个加载到Windows资源管理器中),我可能永远不会关心64.但由于这个限制,我需要它,我现在需要它.所以我可能不得不在Free Pascal中开发那个部分.遗憾的是,除此之外,很少有应用实际上会从64中受益.国际海事组织,大多数用户要么正在喝冷却剂,要么因为被欺骗购买听起来很棒的东西而变得头疼.我认识一个很高兴运行Win7/64的人,所以他有足够的内存来运行VM中的完整拷贝的XP,如果他像我告诉他的那样得到Win7/32,他就不需要.: -
我认为每个人都被硬件制造商欺骗了,特别是RAM经销商本来会有一个非常软的市场.
无论如何,回到手头的问题......我被夹在岩石和坚硬的地方之间.由于M $的架构决策(不允许在Windows资源管理器中使用32位DLL)和感知问题(64位必须是32位,或者32位必须运行在32位),我的客户对我提出了要求. "惩罚核心"或其他东西).因此,我受到很大程度上"人为"的动机的驱使.因此,我必须将其投射到Embarcadero上.但最终,在Delphi中对64位支持的需求是IMO,主要基于BS.但他们将不得不回应它,我也将如此.
小智 5
真正的问题不是技术问题.首先是Borland/CodeGear,然后是Embarcadero,表明他们不喜欢保留多个Windows版本的Delphi.他们推迟了Unicode切换,直到他们完全放弃Ansi OS支持.实际上他们需要支持两者一个Win32编译器/库和一个64位编译器/库,因为使用了32位和64位Windows操作系统.我相信他们正试图尽可能地延迟它,以避免尽可能多地保留32位的.Delphi编译器变得非常古老而且难以实现,但他们决定以非Windows操作系统为目标重写它,我确信驱动程序是将一些Embarcadero数据库工具移植到非Windows 32位平台,忽略了Delphi客户的实际需求并且在跨平台尝试中再次延迟64位编译器和库再次尝试偷工减料以快速交付,从而注定再次失败.固执地,他们不想转为两年的发布周期,因为他们每年都想要新的现金,尽管在如此短的周期内发布真正完善的改进变得越来越困难 - 并且花了将近四年的时间来修复Delphi 2005引入的问题.反过来,他们必须让开发人员努力引入"次要"改进来证明升级的合理性,而不是完全处理64位的东西.
我听说他们想要完全重写编译器而不会失去向后兼容性.考虑到没有语言的完整语法描述(我已经问过,但他们没有,所以我自己可以向公众提供).我可以想象,文档并不像他们想要的那样完整.所以他们可能正在尝试对自己的代码进行逆向工程.
我是Delphi的坚定支持者,我认为2009年和2010年都是很棒的版本(与坚如磐石的#7相比).但缺乏64位支持最终会杀死它们.
回到问题,最大的问题应该是编译器.从16位到32位的转换更容易,因为遗留的较少(delphi 2是32位,而Object Pascal语言比现在简单得多.)我不确定Free pascal.也许他们的代码很容易移植.也许他们失去了一些向后兼容性 当然,你可以问他们.
| 归档时间： |
|
| 查看次数： |
1582 次 |
| 最近记录： |