I may misunderstand Brewman's words here, because he strikes me as a man who knows more about this, but this operation doesn't "strip off high bytes and returns low bytes"... First, it's a "high bit " (not the high byte) we're talking about, or better worded IMHO the most significant bit of the SHORT that GetAsyncKeyState returns. (See here for the msdn doc, and let's stay big-endian for the moment ) Second, this method "strips off" (though I disagree with that terminology, which may be the misunderstanding?) low bits, not high bits. What BitAND does is comparing two numbers by writing them out in binary and returning the number you get when you "and" all the bits, i.e. each binary digit in the result is only 1 when that digit was also 1 in both input numbers. When you write hexadecimal number 0x8000 in binary, you get: 1000 0000 0000 0000. Note that there is only one 1 in that number, which meaning that if you BitAND() that number with any other number, the result ends up being either 0x8000 or 0x0 (which is just 0). Because for every digit except the leftmost one, at least one of the two digits of the compared numbers is 0, so the and-value is also 0. The leftmost one is either 0 or 1: it is certainly 1 in our second comparison number (0x8000), and will be 1 in the result number if and only if it was also 1 in the first comparison number. In this case, the return value of the function has its most significant bit set to 1 if the keycode you gave the function as a parameter is down, and to 0 if it is up. (Or if there was a problem in the method, in which case the entire result value is 0 in total.) /edit: See the keycodes, and again, the MSDN doc of the GetAsyncKeyState function.