4 ms·

Could someone enlighten me why 64 bit seems to be so hard to do on Windows as compared to other platforms?

CamperBob2 14y ago
It's not, at least on MSVC, unless you have a lot of inline asm in your C/C++ codebase. You change a couple of -D flags on the compiler and linker command lines and build with the 64-bit compiler. A few Win32 calls and data types will need to be changed. If you're in the habit of casting pointers to ints or vice versa, you'll need to change those ints to size_t or equivalent types, as you should have been doing all along. Few/no Windows developers should be treating their 32-bit builds as their primary target at this point, unless (as in Mozilla's case) they need to interface with a lot of legacy 32-bit plugins. The correct course of action for Mozilla would be to pressure the plugin developers, though, rather than to put the horse in front of the cart as they're doing. They could have made the same call in the Windows 95 days, when 16-bit code was still viable. It would have been silly then, and it's silly now.
- Derbasti 14y ago
  That does not seem to explain why 64 bit is apparently more problematic on Windows than on other platforms. Could you elaborate on that?
  - CamperBob2 14y ago
    Sorry, I have no idea where they're coming from when they say that. It's got to come down to plugin compatibility. In fact -- again, for MSVC projects -- debugging a 32-bit application on a 64-bit PC is what's painful. There are serious bugs in Visual Studio's WoW64 support that have remained unfixed for years.
- iSnow 14y ago
  >rather than to put the horse in front of the cart as they're doing As a non-native speaker, I am confused. Over here, we put the horse in front of the cart back when we still used carts and horses. Makes more sense to me.
  - codeka 14y ago
    The expression is "to put the cart before the horse", i.e. do things in the wrong order.
  - CamperBob2 14y ago
    As a non-native speaker, I am confused No, you got it right. Cliché fail. :)

It's not, at least on MSVC, unless you have a lot of inline asm in your C/C++ codebase. You change a couple of -D flags on the compiler and linker command lines and build with the 64-bit compiler. A few Win32 calls and data types will need to be changed. If you're in the habit of casting pointers to ints or vice versa, you'll need to change those ints to size_t or equivalent types, as you should have been doing all along. Few/no Windows developers should be treating their 32-bit builds as their primary target at this point, unless (as in Mozilla's case) they need to interface with a lot of legacy 32-bit plugins. The correct course of action for Mozilla would be to pressure the plugin developers, though, rather than to put the horse in front of the cart as they're doing. They could have made the same call in the Windows 95 days, when 16-bit code was still viable. It would have been silly then, and it's silly now.

Derbasti 14y ago
That does not seem to explain why 64 bit is apparently more problematic on Windows than on other platforms. Could you elaborate on that?
- CamperBob2 14y ago
  Sorry, I have no idea where they're coming from when they say that. It's got to come down to plugin compatibility. In fact -- again, for MSVC projects -- debugging a 32-bit application on a 64-bit PC is what's painful. There are serious bugs in Visual Studio's WoW64 support that have remained unfixed for years.
iSnow 14y ago
>rather than to put the horse in front of the cart as they're doing As a non-native speaker, I am confused. Over here, we put the horse in front of the cart back when we still used carts and horses. Makes more sense to me.
- codeka 14y ago
  The expression is "to put the cart before the horse", i.e. do things in the wrong order.
- CamperBob2 14y ago
  As a non-native speaker, I am confused No, you got it right. Cliché fail. :)