Linked by David Adams on Tue 22nd Feb 2011 19:52 UTC, submitted by estherschindler
General Development Your company is ready to upgrade its custom applications from 32-bit to 64-bit. (Finally.) Here's 10 tips to help you make the transition as painless as possible.
Thread beginning with comment 463703
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: ?
by Valhalla on Wed 23rd Feb 2011 15:17 UTC in reply to "RE: ?"
Valhalla
Member since:
2006-01-24

If you're written perfect software, then it's not hard at all. But nobody writes perfect software, and so code might be written with invalid assumptions - e.g that the size of a pointer is the same as the size of a standard integer, or more generically, that a pointer can be stored in an int type. Which is true when the pointer is 32-bit, but when the code is compiled 64-bit, that's not the case, and things either fail to compile, or break with memory issues at runtime.


But why would you assume that a pointer is the size of an int? When dealing with pointers you use pointers, not int's. You want an array of pointers, you create an array of pointers, not an array of int's. A pointer is a data type just like int,short,char,float,double,long and you can perform arithmetic on it, and you can do a simple sizeof to verify it's length. I see no excuses (nor logic) for assuming a pointer is the size of an int, that's just crazy.

Reply Parent Score: 2

RE[3]: ?
by malxau on Wed 23rd Feb 2011 19:44 in reply to "RE[2]: ?"
malxau Member since:
2005-12-04


But why would you assume that a pointer is the size of an int? When dealing with pointers you use pointers, not int's...I see no excuses (nor logic) for assuming a pointer is the size of an int, that's just crazy.


In an ideal world that's all fair and good, but the world is rarely that ideal. One place where this is done in Windows is in the application message pump. Every message has the same two arguments: a WPARAM and an LPARAM. For some messages extra information was required that couldn't fit in two 32-bit fields, so often LPARAM would point to some extra allocation. But for other message types it's a number, and for others it's a flags field...

So when porting to Win64, LPARAM needed to be retyped from LONG to LONG_PTR which allows it to remain a numeric field, but also be long enough to contain a pointer value to support messages that pass pointer values.

The thing for application developers to watch for is imperfect casts. If an app calls "SendMessage( hWnd, blah, blah, (LONG)(mystruct *)foo);" then on Win32 this will work fine, but on Win64 will cause a subtle pointer truncation. if (LPARAM) were used instead of (LONG) things would be fine, but on Win32 those are the same type.

Reply Parent Score: 2

RE[4]: ?
by Valhalla on Thu 24th Feb 2011 18:18 in reply to "RE[3]: ?"
Valhalla Member since:
2006-01-24


The thing for application developers to watch for is imperfect casts. If an app calls "SendMessage( hWnd, blah, blah, (LONG)(mystruct *)foo);" then on Win32 this will work fine, but on Win64 will cause a subtle pointer truncation. if (LPARAM) were used instead of (LONG) things would be fine, but on Win32 those are the same type.

Yes, but again if you follow the API call structure you will be fine, in this case use LPARAM, WPARAM rather than what they happen to be defined as. Which is why it is important to never assume anything about API types since they can change 'behind the scenes' which can break your application if you 'assume' anything. When dealing with foreign code that you can't manipulate, simply stick to the interface provided or set yourself up for a potential ton of headache.

Reply Parent Score: 2