我正在Windows上编写一个用户空间文件系统驱动程序，并且直觉转换是我一直在处理的，因为这个特定的文件系统总是以小端格式存储值，并且驱动程序有望将其转换(如果需要的话)为cpu跑上然而，我发现自己想知道我是否需要担心字节转换，因为据我所知，台式机Windows只支持小端点架构(IA32，x86-84等)，因此，磁盘小端点的价值观是完美的无辜转换。这个观察是否准确，如果是这样，通常可以接受的是假设Windows将始终运行在小端硬件上？另外，甚至有可能(在2011年)在一个大型的仿真器上运行Windows，甚至可以测试字节顺序的问题？
编辑：为了更清楚，我的代码当前工作方式，我在启动时进行字节顺序检查，然后每次从磁盘上加载一个值时，我通过一个内联函数运行它，使用内在函数来改变字节顺序建筑是大端。问题是，我不知道我是否可能错过了一个或多个需要进行转换的地方，最简单的方法是看看我是否搞错了是在大型架构上运行该程序。所以我有兴趣知道(a)如果甚至有必要进行这些检查，因为Windows通常不会运行在小端平台(今天无论如何)，以及(b)我如何可以测试我的代码，看到我不能想到在大型架构上运行Windows的方法，手动反转磁盘上的所有多字节值仍然涉及我可能会拧紧的手动过程。
修改后的问题：
原文链接：https://www.f2er.com/windows/372383.htmlA)如果您的唯一目标是Windows x86或x64，则不需要检查字节顺序。在这种情况下，我甚至不会花时间检查字节码。
B)如果你想检查你的代码的双端支持，我建议将它拆分为自己的跨平台可编译的库。然后编译并运行您喜欢的Linux风格的代码，支持big-endian，看看它是否可行。我还没有听到有任何可以检测到双向问题的编译器或软件。
原来的回应：
据我所知，没有桌面或服务器版本的Windows支持big-endian。 Itanium处理器(我相信总是被称为IA 64，而不是IA32，但我可能是错误的)有能力运行在big-endian，但Windows不支持它。
这并不是说只有Windows 8针对ARM处理器，Windows 8才会是小端。
如果由于某种原因你在Windows上(#ifdef _WIN32)，并且big-endian在从磁盘加载时简单地反转数据结构，并且总是以小端点格式保存，这是更常见的。
