[Webinar] Streamline your web hosting managementRegister Today

x
Solved

# DOWRD =32 bits?

Posted on 2001-06-11
Medium Priority
218 Views
1, I suppose 32 bit DWORD inherits from API written before 32 bit Windows? A 'word' now is 32 bit?

2, How do I do "double precision?" (e.g., from float to double.)

3, Where is Hi word/Lo word? why hi/lo?

Thanks
0
• 4
• 4

LVL 32

Expert Comment

ID: 6178138
1. On WIN32, a DWORD is a 32-bit value.  But its size depends on the platform, WIN16, WIN32, or WIN64.  It is ALWAYS incorrect to assume its size.  If you need the size, get it with sizeof(DWORD).

2. double d;
float f;
f = 1.000;
d = f;   //  f is automatically converted to double

3) HIWORD & LOWORD are macros that make it easy to write Windows version portable programs that access 1/2 of a WORD value.  So if you have a WORD:

WORD w;

// Get the most significant half:

BYTE bh;
bh = HIWORD(w);

// Get the least significant half:

BYTE bl;
bl = LOWORD(w);
0

LVL 32

Expert Comment

ID: 6178140
By the way, a good place to start is Programming Windows by Charles Petzold.
0

Author Comment

ID: 6178357
I guess my first impression was wrong.
I thought DWORD means "Double word." Hence we have HIWORD/LOWORD. If a word conatinas only 2 bytes, then HIBYE/LOBYTE gets one of the 2 bytes in a WORD? This makes no more sense when a word contains 4 bytes?

Can you explain the following definition of HIWORD? The only thing I understand is the cast- "WORD"...

#define HIWORD(l)   ((WORD) (((DWORD) (l) >> 16) & 0xFFFF))

Thanks
0

LVL 32

Expert Comment

ID: 6178405
DWORD does mean Double WORD but how big it is depends on how big WORD is.  WORD does NOT have to be 16-bits.  It's arbitrary.  In WIN32, WORD is 16-bits but as I already said, it DOES NOT HAVE TO BE.  Many, MANY Win16 programmers git bit by sloppy programming when WIN32 came out.

>>>#define HIWORD(l)   ((WORD) (((DWORD) (l) >> 16) & 0xFFFF))

This takes the value "l", shifts it RIGHT (>> 16) by 16 bits, and then masks off the upper 16-bits ( & 0xFFFF).

DWORD dwX = 0x5555AAAA;
WORD wY;

wY = HIWORD(dwX);

wY would end up with 0x5555 in it.

You could also do this without the macro as:

wY = (WORD)((dwX >>16) & 0xFFFF);

Same thing...
0

LVL 5

Expert Comment

ID: 6178602
The confusion stems from the fact that a 'word' ought to be a "machine word" (i.e. the cpu operand size).

However under all Windows versions WORDs, DWORDs etc have been frozen/fixed at 16, 32 bits. This is techanically wrong with regard to the original meaning of the term 'word'.

Rob

Oh and for added confusion there is the WPARAM (word-param) which is... 32bits after all.

0

Author Comment

ID: 6178715
The definition of HIWORD "AND" a 32 bit with a 16 bit. How does that work?
0

Author Comment

ID: 6178723
and what happens when, at the end, you cast a 32 bit into a 16 bit (WORD)? Doesn't the cast end up with the most significant bits (leftmost)?
0

LVL 32

Accepted Solution

jhance earned 120 total points
ID: 6178763
Remember that casts happen only between compatible types and the compiler (usually) does the right thing.  The only reasonable way to cast a 16-bit value into a 32-bit one is to put the 16-bits into the low order 16 bits of the 32-bit value.  So casting 0x0001 into a 32-bit will get you:

0x00000001

So what happens if you AND a 16-bit and a 32-bit value?  Remember that the compiler must cast the types into a common type and so if we have:

WORD w = 0xFFFF
DWORD dw = 0xFFFF0000;

and we do:

dw = dw & w;

What do we get in dw?  Well, the WORD value w gets converted to 0x0000FFFF and the result is 0x00000000.

This raises another question for you to consider?

What is:

w = dw & w;  // ???

(left as an exercise to the reader....)
0

Author Comment

ID: 6178871
A cast from 32 bit to 16 bit leaves the right-most bits.
It seems then "& 0xFFFF" part of the HIWORD definition is redundant..
0

## Featured Post

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question