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.