Holy cow, I wrote a book!
You could actually answer this question (say by coughing up a code
fragment that stores a 16-bit value to memory and then takes it
apart into bytes to see how it got stored,
or by simply hard-coding it based on the target architecture
you are compiling for),
but you'd be making the mistake of answering the question
instead of solving the problem.
The customer liaison explained,
"My customer is having a problem that is caused by a bug in the
SAP BI connector.
the Knowledge Base article,
the problem occurs when the SAP BI server is installed
on a big-endian system."
Okay, with that background, we immediately recognize that
the question is wrong.
The problem occurs when the SAP BI server is running
on a big-endian system.
It doesn't matter what the endian-ness of the Windows machine is,
so any mechanism for detecting whether the Windows machine
is big-endian or little-endian is barking up the wrong tree.
But it turns out that the customer never even had to do this
detection at all.
If you read the Knowledge Base article, it says that the problem
is already fixed.
The fix for this issue was first released in Cumulative
Update 4 for SQL Server 2008 Service Pack 1.
So just make sure you're running
Cumulative Update 4 for SQL Server 2008 Service Pack 1 or higher
(which, if you've been making any attempt at keeping your
server up to date, you've been doing for three years),
and the problem will go away.
The customer liaison thanked us for our assistance,
but nevertheless asked for the code that would detect
the endian-ness of the Windows system.
"How will that help you solve your problem?"
but before the customer liaison answered,
some other people just gave the customer code that
detects the machine endian-ness.
Even though that will do absolutely nothing to solve the customer's problem.
That was the last we heard from the customer liaison.
I'm hoping that they actually installed the service pack
and solved their problem.
And I'm afraid what they're going to do with that code fragment.