我正在Windows上编写用户空间文件系统驱动程序,并且字节序转换是我一直在处理的,因为这个特定的文件系统总是以little-endian格式存储值,并且驱动程序需要将它们转换(如果需要的话)运行。 然而,我发现自己想知道是否我甚至需要担心sorting转换,因为据我所知,桌面Windows只支持小端架构(IA32,x86-84等),因此,磁盘小端值是完美无瑕的转换。 这个观察结果是否准确?如果是这样的话,假定Windows始终在小端硬件上运行,这是否可以接受? 另外,甚至有可能(在2011年)在大端模拟器上运行Windows,甚至可以testing字节序问题吗?
编辑:为了更加清晰,我的代码目前的工作方式,我做启动时的endianness检查,然后每次我从磁盘加载一个值,我运行它通过内联函数,使用内在改变endianness如果架构是大端的。 问题是,我不知道我是否可能错过了一个或多个我需要进行转换的地方,而最简单的方法是看看我搞砸了是在一个大端的架构上运行这个程序。 所以我有兴趣知道(a)是否有必要进行这些检查,因为Windows通常不会运行在小端平台上(现在不pipe怎样), (b)我怎样才能testing我的代码,想不到在大端架构上运行Windows的方法,手动反转磁盘上的所有多字节值仍然涉及一个手动过程,我可能会搞砸了。
所有你会看到的Windows版本都是小端的,是的。 即使在今天 ,NT内核实际上仍然运行在大端架构上 。
改变后的问题编辑:
答)不,如果您的唯一目标是Windows x86或x64,则不需要检查字节顺序。 在这种情况下,我甚至不会花时间检查字节序。
B)如果你想检查你的代码的双端支持,我建议把它分成跨平台编译的库。 然后编译并运行你最喜欢的支持big-endian的Linux风格的代码,看看它是否有效。 我还没有听说任何可以检测双端问题的编译器或软件。
原始回复:
据我所知,没有桌面或服务器版本的Windows支持big-endian。 安腾处理器(我相信它总是被称为IA 64,而不是IA32,但我可能是错的)有能力运行在大端,但Windows不支持它。
这并不是说只有Windows 8针对ARM处理器,Windows 8才是小端的。
如果由于某种原因,你在Windows(#ifdef _WIN32)和big-endian中,只是在从磁盘加载时反转数据结构,并且总是以小端格式保存,而这种格式更常见。