The Endian of Windows

Rick’s got a great post on what big and little endian are, and what the Apple switch has to do with Word for the Mac.

In the comments, Alicia asked about Windows…

I tried to make this a comment on his blog but the server wouldn’t take it.


The answer is pretty simple: For Windows, there are parts of Windows that are endian-neutral (for instance, the CIFS protocol handlers and all of the DCE RPC protocol, etc), but the vast majority of Windows is little-endian.

A decision was made VERY long ago that Windows would not be ported to a big-endian processor.  And as far as I can see, that’s going to continue.  Since almost all the new processors coming out are either little-endian, or swing both ways (this is true of all the RISC machines Windows has supported, for example), this isn’t really a big deal.

Comments (17)

  1. n4cer says:

    "A decision was made VERY long ago that Windows would not be ported to a big-endian processor. And as far as I can see, that’s going to continue."

    What about NT (up to version 4) and the XBOX 360 OS which runs on PPC-based CPUs? Did the PPC NT supported and the one in the XBOX 360 have a little endian mode?

    There’s also CE’s support for PPC up to version 3 IIRC, but I’m mainly interested in the desktop and XBOX 360 OSes.


  2. I can’t speak for xbox 360, but the PPC is one of those "swings both ways" CPUs – you can set it to be either little endian or big endian. We just set it to be little endian.

    The same was true for Alpha and MIPS.

  3. Ryan Phelps says:

    I can understand why DOS/Win95/98/ME wouldn’t be ported to big-endian, but why wasn’t NT designed to swing both ways from the beginning? I think it would be fairly manageable to design facilities to account for the differences, although maybe I’m horribly wrong. Were they already irritated at having to create an OS from scratch and didn’t want to have to worry about processor endianess as well?

  4. Dan McCarty says:

    "I tried to make this a comment on his blog but the server wouldn’t take it."

    What’s up with the MS weblogs servers being so horrible after the site redesign? Sometimes your (and others) blogs are unavailable, sometimes comments are unavailable, and the "Remember me" checkbox is just plain broken.

  5. Dan: As best as I can figure, there were a bunch of changes that occurred when we switched sites.

    Among them were switching hosting providers – the new provider doesn’t have nearly the pipes of the old provider.

    There have also been a bunch of bugs in community server that we exposed.

    The good news is that it IS getting better, and will continue to over the next couple of weeks – Betsy promises us.

  6. Ryan, Some pieces (srv.sys and rdr.sys, for example) were. Some pieces had to (DCE RPC is endian-neutral, and has to interoperate between different-endian architectures).

    For some pieces, it didn’t matter.

    For some pieces, it did. But the bottom line was that we didn’t have a big-endian reference platform against which to test. And since we didn’t have a big-endian reference platform, we knew that we were going to have bugs sneak in.

    And we knew that those bugs were going to be compounded by applications that weren’t willing to deal with endian issues.

    It was just simpler to lock into little-endian mode.

    At some point, this decision might change. If some new processor comes on the market that’s big-endian only, Microsoft might bite the bullet and switch.

    But that’s highly unlikely – the trend is to make processors work in both big-endian and little-endian mode, rendering the discussion moot.

  7. dfgdfgfd says:

    Makes you wonder why Intel and AMD dont provide a way to switch endians to aid emulation since Pacifica is a big drive for virtualisation in the next chips.

    I for one cant wait for Apple or whoever to adopt Cells, id jump in a flash to any platform using them. I can see Apple moving to them in the next 10 years (again).

    The next big thing to hit gaming is a "Physics" Processor.

  8. Edward says:

    Wasn’t the reason Virtual PC for Mac 6 didn’t run on Apple G5s because the PPC970 doesn’t swing both ways like the G4s did?;en-us;827904.

    How about the Cell processor? If that also is fixed in that way it would be a major barrier to Microsoft adopting it and if the performanc claims are to be believed could be a major workstation platform for Linux.

  9. Andreas Haeber says:

    In [1] it states this about the endianity of Xbox 360:

    "Xenon is a big-endian system. Both the CPU and GPU process memory in big-endian mode. Games ported from little-endian systems such as the Xbox or PC need to account for this in their game asset pipeline." (at the bottom of the article – Xenon is the codename of the CPU of the Xbox 360)

    Other places you can read that the OS of Xbox 360 is based on Windows XP (or similar).

    My guess is that the Xbox team has their own branch of the code and have removed all parts not important for Xbox (like MS Paint, etc) in addition to fixing the code assuming little-endian to do big-endian. Since they know the hardware configuration, and part of the software available(*), too they can ensure very well that it will be stable.

    Wonder if someone can confirm/deny if my guesses are true, but I don’t find it hard to believe that it is so 🙂

    (*) They produce the SDK used during game development, which sets a baseline at least.


  10. Mike says:

    Ryan wrote:

    "but why wasn’t NT designed to swing both ways from the beginning?"

    Could it be because Intels i860 was (like every Intel CPU?) little-endian? 🙂

  11. Roger Binns says:

    In what way is CIFS endian neutral? Everything is in LSB and since there were no MSB machines with CIFS servers there could never have been any interoperability testing.

    One influence of RISC processors on CIFS was the aligning of fields on word boundaries in new additions to the protocol. Oh, and Unicode was added. As was DCE/RPC over CIFS. And backwards compatibility was retained. Except where it wasn’t.

    So nowadays you have somewhat of a mess, some fields in Unicode even from clients who say they don’t support it, varying alignment depending on how old a particular field is. And certainly no option for endianess neutrality.

    That is unless there is a story you aren’t telling us 🙂

  12. Roger: The source code to the CIFS handlers in Windows (srv.sys, and whatever they’re calling the redirector these days) is built endian-neutral.

    In other words, there’s a wrapper macro around every access to CIFS structures (SmbReadShort, SmbReadLong, SmbWriteShort, etc). That way if NT is ever ported to a big-endian machine, the code in the redir and server won’t have to be changed, just recompiled.

    Now then, since we’ve never ported the NT redir or server to a non little-endian platform, this has never been verified. But the intent was there from the get-go.

  13. Btw, Roger, what do you mean "dce/rpc over CIFS"? Do you mean the ncacn_np RPC protocol?

    Then it’s not dce/rpc over CIFS, it’s dce/rpc over named pipes – ncacn_np works just fine locally, without involving CIFS.

  14. Roger Binns says:

    My interpretation of endian neutral was diffferent than yours 🙂 The protocol has fixed endianess and you just have macros to convert between the fixed endianess of CIFS and whatever the host is using (the equivalent of htons/ntohs etc). Doing that has always been normal to me and not something to call out. If you write Java code, you don’t even get to exploit the host endianess (you end up with horrible code to reassemble the bytes with shifting, ands and ors).

    In the case of DCE/RPC, yes it is just named pipes to you. However for those of us not writing code that sits inside the Windows kernel (such as user space on a Unix box) then it is yet another nested layer of data encoding and marshalling that has to be dealt with in a CIFS server. And since DCE/RPC does have a per PDU endianess flag, that could be different than the surrounding CIFS!

  15. Roger, the protocol on the wire is little-endian.

    But the code to interpret this protocol is ALSO endian neutral – the code doesn’t access fields in the blocks of memory assuming that they are little-endian, instead it uses macros to ensure that the access works, regardless of the endianness of the host processor.