How easy can one port a product from Win32 to x64? It depends on whether or not you ignore what your mom told you: "don't listen to strangers..." <- ps: ignoring this, only applies to developing!
You can learn from other ones faults, right? So in the past, years ago, when the MSDN magazine and others told us to use INT_PTR instead of INT etc at certain code you know the drill, I was not to lazy, to modify my code. So I listened to strangers...
So, today, I took an old project, still running and shining, ISP Session, and wanted to offer x64 support. I can tell you this; If I had been only had been listing a little better to the wise guys!
Just kidding. In short, Everything works on x64 systems, Visual Studio 2005, it is a 32 bit process, but it debugs fluently a 64-bit process. (I attached to W3WP.exe for instance). It stopped at my breakpoints and shows source code, I stepped through etc. It was a good experience!
So, here for the MVP part, the good words for Microsoft!
Of course, you bet, my code did not 'just compile' and run. Not because of ignoring my 64-bit warnings that the Visual Studio compiler might have produced, but because of 'optimizing' some parts of my code in the past, that I should have done better.
Here they are...
1) If the MSDN tells you to allocate a CreateStreamOnHGlobal through a GlobalAlloc that must be using 'movable memory' please do so! Well, I found that the code ran faster when using fixed memory (it was at a case, where the memory stream did not have to grow)! But Win x64, does not like this, and punished me by presenting a GP.
2) If you think that BSTR work exactly the same as before and you don't have to modify code at that, you're right, but this was not applying to me! I was managing my own BSTR allocation replacements (again because of improved efficiency on IIS on this) and I found that a BSTR allocation is somewhat different. It is as follows on 64-bit systems:
BSTR memory layout: [4 bytes (not used)] [4 bytes (length prefix)], wchar_t[length], [\0], total length of allocation is aligned on 16 bytes.
The 4 unused bytes are rather mysterious since SysStringLen() still returns a UINT length (not a UINT_PTR). Maybe this is because of future plans, far, far away?
On 32-bit systems, the prefix is really 4 bytes, and not 8.
For those who are interested in the details:
download it: http://technolog.nl/eprogrammer/bstrnocache.zip
(In combination with my CComBSTR replacement, BSTR heap management performance is outstanding, without using any cache)
3) Some third party code, ZLIB had to be recompiled into a valid 64-bit lib. If you forget to do this, your DLL will link to the wrong 'guy'. B.t.w. zlib version 1.2.3 just recompiled perfectly (kudo's to Jean-loup Gailly and Mark Adler!). To tell the C++ compiler to link to the correct lib, I had to add some conditional code in stdafx.h. Maybe, there is a smarter way to do this. Report me if so...
#ifdef
WIN64
#pragma comment(lib, "zlib64.lib")
#else
#pragma comment(lib, "zlib.lib")
#endif
After making my product strict again, it works flawless on x64 systems (and faster!).