DOCUMENT:Q102025  25-AUG-1993  [W_NT]
TITLE   :INF: Explanation of Big Endian and Little Endian Architecture
PRODUCT :Windows NT
PROD/VER:3.10
OPER/SYS:WINDOWS
KEYWORDS:

----------------------------------------------------------------------
The information in this article applies to:
 
 - Microsoft Windows NT operating system, version 3.1
 - Microsoft Windows NT Advanced Server, version 3.1
----------------------------------------------------------------------
 
SUMMARY
=======
 
When designing computers, there are two different architectures for
handling memory storage. They are called Big Endian and Little Endian
and refer to the order in which the bytes are stored in memory.
Windows NT was designed around Little Endian architecture and was not
designed to be compatible with Big Endian because most programs are
written with some dependency on Little Endian.
 
MORE INFORMATION
================
 
These two phrases are derived from "Big End In" and "Little End In."
They refer to the way in which memory is stored. On an Intel computer,
the little end is stored first. This means a Hex word like 0x1234 is
stored in memory as (0x34 0x12). The little end, or lower end, is
stored first. The same is true for a four-byte value; for example,
0x12345678 would be stored as (0x78 0x56 0x34 0x12). "Big End In" does
this in the reverse fashion, so 0x1234 would be stored as (0x12 0x34)
in memory. This is the method used by Motorola computers and can also
be used on RISC-based computers. The RISC-based MIPS computers and the
DEC Alpha computers are configurable for Big Endian or Little Endian.
Windows NT works only in the Little Endian mode on both computers.
 
Windows NT was designed around Little Endian architecture. The
Hardware Abstraction Layer (HAL) is written so that all operating
system-related issues are automatically handled. Therefore, it is
possible to create a HAL that could work on Big Endian architecture.
The basic problem with porting the code has to do with the way the
code is written for all programs. Code is often written with the
assumption that Big Endian or Little Endian is being used. This may
not be specific to the HAL; it could be something as simple as bit
masking for graphics. To clarify this concept more, two programming
examples follow.
 
Example 1
---------
 
   struct
   {
      WORD y;
      WORD x;
   } POS;
 
   lparam = (DWORD) POS;
 
Basically, there is assumption in the code that Little Endian is being
used. The switching of the bytes is being assumed in the 'C'
structure. This is faster on Intel architecture, but will not work
with Big Endian.
 
Example 2
---------
 
Another example is a common practice of using bit masks. The following
is an example of defining a bit mask:

   #define BITMASK    0x0008
 
This allows you to check if the 4th bit is a 1 if you AND it with
another number. It also allows you to set the 4th bit by OR-ing it
with another value. The problem comes when you OR or AND this with
DWORD (Double Word) or anything other than a WORD size value. This
causes strange things to happen and unexpected results. You might make
assumptions about how it works with Little Endian, yet it won't work
the same way with Big Endian. A large amount of code is already
created with these assumptions built in.

Additional reference words: 3.10 uuh apple mips
KBCategory:
KBSubcategory: hrdwr

=============================================================================

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS
PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND.  MICROSOFT DISCLAIMS
ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  IN NO
EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR
ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,
CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF
MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.  SOME STATES DO NOT ALLOW THE EXCLUSION
OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES
SO THE FOREGOING LIMITATION MAY NOT APPLY.

Copyright Microsoft Corporation 1993.