64-bit development, it's no Fad

Have you been thinking about porting that existing 32-bit application to a native 64-bit application?
 
There are things to consider before jumping in head first and I’ll go over some of my experiences in this seemingly daunting endeavor.
 
First things first, mental preparation! In the spirit of preparation and a sprinkling of encouragement, I’ll say this despite information found elsewhere: "Porting existing applications to 64-bits really isn’t all that difficult as long as you start your journey with a project that at least loosely followed nearly any recognized coding practice".

Things to keep in mind:

Registry:

On a 32-bit machine your registry entries should go into "HKEY_LOCAL_MACHINE\Software\" or "HKEY_CURRENT_USER\Software\". However, if the same 64-bit application is installed on a 64-bit machine (running a 64-bit version of Windows) then your registry entries will automatically be placed into "HKEY_LOCAL_MACHINE\Software\ Wow6432Node\" or "HKEY_CURRENT_USER\Software\Wow6432Node\". In addition, your application will also be directed at this key when it reads from the registry.
 
This is all handled for you automatically by the underlying windows API and is (for the lack of a better term)... child’s-play. Unless you happen to have an product which contains multiple executables of which are a mix of 32 and 64-bit components - accessing the same common registry key can become challenging in this case.

Program Files:

The same principal that applies to the registry also applies to the "C:\Program Files\" directory with the exception that the naming convention what no adhered. On a 64-bit version of windows 64-bit applications will access the "C:\Program Files\" directory, while 32-bit applications will automatically be directed to "C:\Program Files (x86)\".
 
This also applies to the "Common Files" location which is traditionally stored under the program files directory. 64-bit versions of Windows will contain two "Common Files" in two separate locations: One under "C:\Program Files\" and one under "C:\Program Files (x86)\" – respectfully.

Other Folders:

You find this method of directly redirection being applied across the OS in many different locations, such as "C:\Windows\System32" to "C:\Windows\SysWOW64". Yes! That's right, the 64bit files are under "C:\Windows\System32", while the 32-bit files are under "C:\Windows\SysWOW64". - It makes perfect sense to me too!

Integers:

Or size_t to be specific. Once you switch your compiler over to 64-bit, you find that any standard function that returns the size of anything is now 64-bits. This includes functions like strlen(). However, while you can now pass strings with 18 quintillion characters to strlen(),I highly recommend that you keep track of the length of excessively long strings using other methods.
 Think about this for a minute. Are you going to change that existing use of strlen() to now set a 64-bit integer or are you going to typecast the return value to a 32 bit integer.

Pointers:

Pointers are now 64-bits. This means larger addressable spaces but could also mean that you have to change some existing bad code. For example, a dialog call back as follows works great in 32-bit environments but will prove catastrophic in 64-bit environments.

//Works great in 32-bit but explodes when compiled as 64-bit
// because it returns a 32-bit value and the result can be truncated.
int CALLBACK dialogProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
. . .
}
 
DialogBox(GetAppInstance(), MAKEINTRESOURCE(IDD_TEMPLATE), NULL, dialogProc);
 
//This works great in both 32-bit and 64-bit
// because it returns a 64-bit value.
INT_PTR CALLBACK dialogProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
. . .
}
 
DialogBox(GetAppInstance(), MAKEINTRESOURCE(IDD_TEMPLATE), NULL, dialogProc);

Shell Integration and Explorer Context Menus:

You cannot load a 64-bit shell extension into Windows Explorer using a 32-bit OS (for painfully obvious reasons), but you also cannot load that 32-bit shell extension into Windows Explorer when using a 64-bit OS. Why? Because the explorer executable is 64-bits and cannot load a 32-bit DLL.

Is this code snippet, product or advice warrantied against ill-effect and/or technical malaise? No. No it's not! Not expressed - Not implied - not at all.