MSDN is a large knowledge base, so maintaining and keeping it up-to-date is an extremely difficult and perhaps almost impossible task. In forums, there are many questions asked by programmers who are involved into 64-bit software development and who are embarrassed by descriptions of some functions in MSDN.
For example, take the discussion "MSDN 64-bit issue". Figure 1 is a screenshot showing the description of the function CListCtrl::SetItemData in the on-line version of MSDN. Although this post is being written in 2010, the function description is still incorrect. And it is most likely that many other MSDN materials are still obsolete from the viewpoint of 64 bits.
Figure 1 - Description of the function CListCtrl::SetItemData in MSDN Library Online
Only the argument was changed in the description of the function CListCtrl::SetItemData. The type of the parameter dwDara was changed from DWORD to DWORD_PTR. It is the same with the description of the function GetItemData. Perhaps this modification was made in some automated mode relying on the new header files. But the descriptions of the functions themselves remain obsolete and mention the "32-bit value".
Here is a question. Maybe the function prototype has been changed but the function still saves data in the 32-bit mode? We may answer "no" relying on the following reasons:
1) Logical reason. You often need to associate rather many data with a list item. In this case the data are untied into a structure and the pointer assigned to it is saved into the function SetItemData. Win64 API developers could not have deprived programmers of this capability, so the function must be able to store 64-bit pointers.
2) Practical experiment:
list.SetItemData(0, 0x1111111122222222ui64); DWORD_PTR value = list.GetItemData(0); if (value == 0x1111111122222222ui64) MessageBox(_T("OK"));
Successful launch of this code in a 64-bit application confirms that SetItemData can store 64-bit values.
Conclusion. Descriptions of SetItemData, GetItemData and some other functions in MSDN Library are obsolete. MSDN materials are regularly updated and perhaps the error we have described here is corrected by now. But if you have encountered such a case, try experiment to check the properties of the function you are dealing with.