> I have not really written much of Windows code, so forgive my ignorance but: What is actually so hard about porting 32-bit -> 64-bit applications on Windows

> I have not really written much of Windows code, so forgive my ignorance but: What is actually so hard about porting 32-bit -> 64-bit applications on Windows Speaking strictly about things surrounding your code, as opposed to the code itself, there's stuff you just don't have on Linux. On Linux pretty much everything is open source and provided by your distro, built for your architecture. The need for compatibility layers are absolutely minimal. This has a resounding positive effect in that quite a lot of things can be assumed fixed and in place. On Windows, not so much. Most applications are pre-built by others. Most are 32-bit. So Microsoft tries to maintain backwards compatible execution environments for both 32-bit code and 64-bit code in Windows. This means that 32-bit processes trying to access system DLLs, will need to find 32-bit system DLLs somewhere. Same for 64-bit. So you have duplication of system-DLLs, in different folders. You can't just assume a standard, fixed path will lead you to the right place. For the COM subsystem, all the available components an application can access is stored in the registry, alongside their physical path on disk. You may need different DLL-files for these COM components in 32-bit processes and 64-bit processes. So now you need the registry to point to different locations based on the bitness of the application running. So yeah. Portions (but not all parts!) of the registry is also duplicated with different references for different processes. That means that when going from a 32-bit process to 64-bit process, all things you've previously written to the registry... May not be there for you to read in your 64-bit process. And you better make sure your installer is the same bitness as your process... Or you know what? That 32-bit installer wont be allowed to prime the 64-bit registry your application needs! This may mean that all COM components you've registered in your installer, now is inaccessible to your (and other) applications because they are 64-bit. And I'm sure the list goes on. These are just the most obvious non-pointer based things I can think of which complicates matters. In short: On Windows... Keeping everything 32-bit and closing your eyes to all terrible things mentioned above will ensure your application keeps working, because Microsoft put in the effort to guarantee that. The second you step into 64-bit, you need to have all these things solved. There's no going half-way. So most people who has little to benefit from 64-bit executables simply don't.