在Linux上如何处理向64位的转换

在Linux / Unix上如何处理向64位的过渡？Windows世界似乎仍然有问题，我很好奇* nix世界如何处理它。

使内核的64位所需的工作做了一长串时间前使用DEC Alpha系统。但是，程序是另一回事。

到目前为止，我所看到的普遍共识似乎是：

• 具有混合二进制文件的系统的单独目录/lib和/lib64目录
• 编译为64位；如果编译失败，请重新编译为32位，直到可以将源清除为64位为止。

除此之外，您真的不会从混合的32/64位版本中看到很多“麻烦”。

Windows和* ix使用不同的数据模型进行过渡。该UNIX.org 页面有些陈旧，但是仍然提供了一些折衷的概述（请注意，该内容long long后来添加到C99中，并且要求至少为64位）。您还可以查看有关同一主题的Wikipedia文章。截至UNIX.org文章的末尾主张，大多数类UNIX系统已经走了与LP64，其手段long，long long以及指针均为64位。

Windows使用了所谓的LLP64数据模型，这意味着only long long和指针是64位的。 long仍然是32位。部分原因仅仅是因为他们不想经历并修复假定long适合的损坏代码int。

由于Linux发行版主要是OpenSource，因此已经进行了相当大的过渡。除非您使用专有软件（例如Skype），否则您可以运行纯64位系统而没有任何缺点。

但是，恕我直言，真正的区别在于，相对于开放式而言，专有权要高得多，而对于unix与Windows而言，它是专有权，因为通常是首先移植的开源软件（某些志愿者需要重新编译某些东西-可能解决了一些编译问题）-或在大多数情况下不移植到除了重新编译之外的所有内容都没有；）-最后移植的财产。

也许在Linux上您可能还会有存储库，因此安装可以自动进行-您无需选择64位或32位版本（系统会自动选择您的版本）。在Windows上，程序已下载并且具有单独的64位和32位版本：

• 将服务器上文件的大小加倍
• 要求用户知道他/她的版本。甚至它们之间有所不同

我猜这就是Windows二进制文件通常为32位的原因-它完全适合所有人，并非所有人都使用64位版本。

实际上，请在ACM队列中尝试“通往64位的漫长之路”：http : //queue.acm.org/detail.cfm?id=1165766 ，后来ACM通讯部将其选出。第一个64位微型处理器是MIPS R4000，它在SGI Crimson 1Q1992中发行，当年12月Alphas发行。

R4000最初以32位模式运行，然后以64/32模式运行，即64位OS，64或32位用户代码。Alphas始终仅在64位上运行UNIX（这是一个合理的选择，因为没有安装32位应用程序。）

在1990年代后期，大约在XFS移植到Linux（它确实需要64位）的时候，SGI致力于64位大小的Linux（可在Itaniums上运行）。