我很惊讶地看到Adobe discontinued the 64 bits version of Flash for Linux。虽然有一个新的32位版本，Adobe建议用户使用32位版本的Firefox。
想知道，因为我还没有那么做， 难以将应用程序移植到64位？除了库更改和重新编译（Makefile中的设置）之外，是什么让端口变得困难？ （Flash就是一个例子）
答案 0 :(得分：7)
如an Adobe blog post所述，Flash的ActionScript引擎有一个JIT编译器，可以将ActionScript代码编译为本机代码。
x64与x86具有非常不同的指令集。因此，使JIT编译器生成x64代码是一项非常重要的任务，并且比将所有单词设为64位要复杂得多。 ： - ）
答案 1 :(得分：2)
将应用程序移植到64位的真正推动者是每个操作系统似乎都会按原样处理原始类型。例如，在大多数linux环境下，long在32位系统上是4个字节，在64位系统上是8个字节（32位= 4字节64位= 8字节。）同时，int保持4个字节64位和32位系统。在Windows下，相反似乎是正确的，long始终保持4个字节，而int在32和64位之间切换。
也就是说，我已经将一个中等大小的项目移植到32位到64位的Linux（大约25,000行代码）之前，只需要在汇编代码（GASM）中进行更改，这会对数据类型做出几个错误的假设长4个字节。除此之外，我没有遇到任何问题，这表明如果您在第一次开发时严格注意数据类型，移植应该是无缝的，可能只需要更改某些编译开关（如-fpic）。有一些在我的移植经验中出现了真正令人头疼的角落情况，但我认为它们主要是由于某些GASM的未定义行为而不是移植本身。
答案 2 :(得分：1)
如果使用大量的整数和浮点数，那么让它适当地工作可能会非常复杂，尤其是。如果它是一个联网的应用程序。
将xMule移植到64位花了两年多时间，我不相信它的父项目eMule有64位。
答案 3 :(得分：1)
理想情况下，它应该是重新编译，实际上需要花费大量精力。即使很简单，质量保证团队仍然需要全面扫描以证明其有效并且总是需要一段时间。
答案 4 :(得分：1)
答案 5 :(得分：1)
我认为明显的问题是可变大小（例如，大多数64位编译器上的long是64位），这会混淆使用大小相关操作的任何内容，例如位移/一些指针算法。我认为adobe不能被扫描并确保交叉兼容性。特别是当90％以上的浏览器使用32位版本时，我知道闪存在64位IE上没有用过，但即使64位Windows 7也默认使用32位版本。
如果您感兴趣，请点击此处提供大量信息：