I have recently ported DP4 onto 64-bit Windows, coincidentally at the same time as porting MAF to 64-bits on my Mac Pro. I had to make exactly one source code change to get MAF to work, though later on several dozen more to ensure that all the MAF diagnostic messages were correct in both the 32-bit and 64-bit versions. For porting DP4, admittedly a larger project, I had to make hundreds of changes, almost all of which were in Windows specific parts of the code. Despite its plethora of ugly data types such as DWORD, LONG, DWORD_PTR and so on, it was in Windows specific code that I had problems. The Win32 API’s insistence on the use of WPARAM , LPARAM, and LRESULT types means that programmers are forced to use casts: casts which may well subsequently turn out to be wrong – types such as DWORD_PTR were added to the API quite late on, so older code may use DWORD instead. When this has been done in an explicit cast the code will be wrong in the 64-bit world, but the compiler probably won’t warn you. Porting older programs with a lot of user interface would probably be very difficult – I’m not surprised that Visual Studio 2008 is still a 32-bit program even in the version intended for 64-bit Windows.
Eventually I got DP4 working nicely in the 64-bit world, and 64-bit and 32-bit DP4 programs can happily live together and communicate with each other. However, I can’t help feeling that in a few years time I’ll have to go through all this pain again, because the Windows 64-bit model is broken: int and long are both still 32 bits, while size_t is 64 bits. In particular this makes life difficult when using printf() style functions, especially as support for the z size specifier cannot be relied on in a program intended to be portable. Programs can’t take advantage of the wider registers unless they use long long types, making it more difficult to make a program portable.