Estou escrevendo um driver de sistema de arquivos do espaço do usuário no Windows e conversões de endianidade são algo com o qual tenho lidado, pois esse sistema de arquivos em particular sempre armazena valores no formato little-endian e espera-se que o driver os converta (se necessário) para a CPU está correndo. No entanto, me pergunto se preciso me preocupar com conversões de endianness, já que, até onde eu sei, o Windows para desktop suporta apenas arquiteturas little-endian (IA32, x86-84 etc.) e, portanto, o disco valores little-endian são perfeitamente bons sem conversão. Essa observação é precisa e, em caso afirmativo, é geralmente aceitável supor que o Windows sempre esteja sendo executado em hardware little-endian? Além disso, é possível (em 2011) executar o Windows em um emulador big-endian ou algo assim, de forma que alguém possa atétest para problemas de endianness?

Editar Para maior clareza, da maneira como meu código funciona atualmente, eu faço uma verificação de endianness no momento da inicialização e, toda vez que carrego um valor do disco, eu o executo através de uma função embutida que usa um intrínseco para alterar endianness se a arquitetura é big endian. O problema é que não sei se posso ter perdido um ou mais desses lugares onde eu precisava fazer uma conversão e a maneira mais fácil de ver se eu errei é executar o programa em uma arquitetura big endian. Então, eu estou interessado em conhecer(uma se for necessário fazer essas verificações, já que o Windows normalmente não roda em plataformas little-endian (hoje mesmo), e (b) como eu poderia testar meu código, já que não consigo pensar em uma maneira de executar o Windows em uma arquitetura big endian e revertendo manualmentetodo os valores multibyte no disco ainda envolvem um processo manual que eu poderia estraga