为什么Windows下64位的long是4字节？

C++

这确实是一个历史遗留问题。简单来说，在设计64位编译器和运行时的时候，当时的架构师可能犯了一个历史性的决策失误：将64位的 long 定义成了4字节。而这个决定一旦做出，后续就很难更改了。从技术标准的角度来看，C/C++ 并没有明确规定 long 必须是8字节，也没有规定 long 的大小不能小于指针类型。因此，将 long 定义为4字节其实是符合语言规范的。但符合规范并不意味着这个设计就能满足人们的期望。然而，人心是善变的。在当今的时代，人们受各种开源工具和类 Unix 系统的影响较大，普遍认为在64位系统中，long 应该是8字节。但在当初设计64位系统时（大约是在1999年左右），当时的人们对 long 的期望并非如此。要知道，第一个支持64位的 Windows 系统直到2001年才发布（针对 Itanium 64 架构）。从设计 long 的大小到完成编译器、Windows 运行时并最终发布，至少需要两年时间，甚至可能更久。所以，把时间推回到1999年是合理的。在1999年的微软，可以说是如日中天，正处于巅峰状态。Windows 95 和 Windows 98 的巨大成功让微软在全球范围内占据了绝对主导地位。至于 linux？那时的 linux 还非常稚嫩，甚至连超过8GB的硬盘都不支持，安装它的人也寥寥无几。对于微软来说，linux 根本不值得特别关注。那么，为什么这位架构师会坚持将 long 定义为4字节？毕竟，当时 int 已经是4字节了。虽然我没有确凿的证据来证明这一点，但我可以提供一种推测性的解释。如果你愿意听我吹一吹，那就继续往下看；如果觉得不合理，那也可以一笑置之。我认为，这种设计可能与微软长期以来对向前兼容性的执着有关。向前兼容性本身是一种非常好的理念。谁不希望软件能够在旧版本上顺利运行？然而，如果将向前兼容性提升到过于严格的道德高度，以至于影响到其他更重要的设计决策，那就得不偿失了。就像传宗接代是一种良好的传统观念，但如果为了实现这一目标而不择手段，甚至牺牲了自己的尊严和未来，结果可能会适得其反。在比1999年更早的年代，计算机世界充满了各种各样的编译器和操作系统，它们之间的整数类型大小差异很大。例如，某些平台上的 int 可能只有16位或24位，而 long 的大小也可能不尽相同。面对这种混乱的局面，微软采取了一种看似聪明的策略：通过 typedef 来定义自己的整数类型。比如，他们定义了 INT 表示 int，LONG 表示 long，Dword 表示 unsigned long。这样一来，无论底层平台如何变化，只要修改对应的 typedef 定义，就可以轻松适配新的环境。举个例子，假设某个新平台上的 int 只有24位，微软只需将 INT 的定义改为 typedef special_bits32_int INT 即可，无需大动干戈地调整整个代码库。这种设计在当时看来非常优雅，也为微软的跨平台开发提供了便利。然而，随着时间的推移，这种对向前兼容性的过度追求逐渐成为了一种负担。当64位系统的设计提上日程时，微软可能依然受到这种思想的影响，试图尽量避免打破原有的代码生态。于是，他们选择保持 long 为4字节，以确保现有代码能够在新的64位环境中无缝运行。尽管这种做法在短期内减少了迁移成本，但从长远来看，却导致了与主流趋势的偏离。当然，除了向前兼容性的考虑之外，还有其他可能的因素影响了这一决策。例如，当时的硬件环境、性能优化需求以及对未来发展的预测等都可能发挥了作用。无论如何，这一决定已经成为了历史的一部分，而我们也只能从中吸取经验教训。总结来说，微软在64位系统中将 long 定义为4字节的决定，既是出于对语言规范的遵守，也是受到当时技术背景和公司文化的影响。尽管这一选择与今天的主流观点不符，但它背后反映的是一种复杂的技术权衡过程。而对于我们这些后来者而言，理解这段历史不仅可以帮助我们更好地应对类似的挑战，也能让我们更加珍惜当前的技术进步和发展成果。