If I wanted to make a game that could run on both 32 bit and 64 bit systems without something like a vm... would I have to make 2 different games? Or could I just run it through something after coding it for one or the other to make a version that works for the other? Or something? I figured it might be a good idea to ask this question in advance. Also, I'm just curious.

Part of the reason for using higher level languages like C is so that you don't have to write your code for a specific CPU. While you might have optimizations that target a specific platform or CPU, for the most part it's just a matter of specifying what CPU architecture to compile for.

If you're referring specifically to x86/x64 platforms, x64 (or amd64, or whatever) features a backwards-compatibility mode that most mainstream OSes use to run 32-bit software natively (Linux requires specific compatibility layers to be installed, while Windows and OSX do it out-of-the-box,) so no alterations or recompiling should be required.

Of course, if your code takes specific advantage of 64-bit features, it may not build for x86 in the first place, which would require modifications, but if it's just written in plain-vanilla code for whatever language you're using there shouldn't be a problem.

"'Legacy code' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrupwww.commodorejohn.com - in case you were wondering, which you probably weren't.

64-bit Windows should still be able to run 32-bit Windows binaries, but you may need to use compatibility mode due to breaking changes made since Windows XP. Just right click on the shortcut and look at the Compatibility tab.

Thesh wrote:64-bit Windows should still be able to run 32-bit Windows binaries, but you may need to use compatibility mode due to breaking changes made since Windows XP. Just right click on the shortcut and look at the Compatibility tab.

At a guess, I think gd1 has experienced the problem with 64-bit code not running on 32-bit systems (which is natural enough, it's engineered to be backwardsly compatible with old code on newer machines, not new-style code on unimproved machines) or perhaps some of the system calls implemented only in a later version of Windows ("The procedure entry point CancelIoEx could not be located in the dynamic link library KERNEL32.dll" or some variant of that problem, forced by dropping suppoort for older methods) even if the 'bitness' is the same.

(To gd1…)In general, you should be able to run anything older on a new system. And, as alluded to in the above quote, there's complications as newer versions of an OS might implement security restrictions such as no direct access to various resources the older OSes gleefully allowed to be poked and prodded directly, when your program was written at such at a time when (best practice or otherwise) it was possible for a program to be written with no need to navigate tightened-up Hardware Abstraction Layers, User Access Controls or whatever else. And, even then, it may be possible to force it through a suitable Compatibility Mode that acts like a partial-VM layering. Other times, it's more awkward.

But with the willingness to support them, a developer who isn't entirely at the whim of his IDE package ought to be able to produce a executable that runs across a range of any given family of architecture, or indeed even across an extended family of architectures and middleware (perhaps by a sufficiently smart and adaptable main-loader that detects which of various back-loader variations ought to be called upon, and extra kudos if that font-loader is written to be suigably polylingusitic in its instruction-set and not just cross-dialect compatible).

Often, though, it's the choice of compiler (and the version) that may dictate that code is produced that is (say) XP-incompatible, even if you specifically ask it to produce Winx86-32 code (that should run on 64-bit), Winx86-64 reoptimised code (not usable on 32-bit), an OSX version (I know it is done, though I'm out of my depth as to what distinctions may in turn divide the OSX package versions), a linux(32/64) redistributable package, etc, as separate compiled output projects to be supplied as separate downloads/located accordingly on an installation media to be chosen accordingly by the end-user.

So sad that I can't play planetside 2 or Mechwarrior Online anymore because of their upgrading to 64 bit.

Anyways, thanks for the answers. I'm a long way off from actually making a game (laziness, learning, etc.), but it's nice to know this stuff in advance.

How old is your computer that it's 32-bit? I'm actually pretty surprised that any system new enough to be able to run Mechwarrior Online (it was a pretty demanding game, CryEngine as I recall) was not 64 bit.

Well, there's also the matter of whether they're running a 64-bit capable OS - I've even seen vendors shipping 32-bit Win10 on 64-bit capable hardware. Not sure why they'd do that, unless licenses cost more for one than for the other...? But it is a thing.

"'Legacy code' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrupwww.commodorejohn.com - in case you were wondering, which you probably weren't.

commodorejohn wrote:Well, there's also the matter of whether they're running a 64-bit capable OS - I've even seen vendors shipping 32-bit Win10 on 64-bit capable hardware. Not sure why they'd do that, unless licenses cost more for one than for the other...? But it is a thing.

32-bit Windows 10 does officially require less RAM (1 GB vs 2 GB)... though in practice either version of Windows 10 will be unusable with less than 4 GB of RAM.

Ah, that's probably it - even if it's unusable at the listed minimum, it's probably more usable at 2-4GB than the x64 version, which means vendors can sell a cheaper base system without worrying about customers complaining.

"'Legacy code' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrupwww.commodorejohn.com - in case you were wondering, which you probably weren't.

So sad that I can't play planetside 2 or Mechwarrior Online anymore because of their upgrading to 64 bit.

Anyways, thanks for the answers. I'm a long way off from actually making a game (laziness, learning, etc.), but it's nice to know this stuff in advance.

How old is your computer that it's 32-bit? I'm actually pretty surprised that any system new enough to be able to run Mechwarrior Online (it was a pretty demanding game, CryEngine as I recall) was not 64 bit.

Okay, I'll just lay it out:I want to make a game using defold, but I want to run it on this computer (32 bit) and probably program it on this computer. I have a laptop that's 64 bit, but I don't like laptops. I mean, I'm lazy so this isn't something I'm stressing about too much anyways though. I'm just scouting out potential problems to make excuses for my laziness know about them in advance.

Well I think you already got the answer to your original question, but in short yes, 32 bit programs can run on 64 bit systems, and it happens all the time. Tons of commonly used applications, including many games, are still 32 bit.

So sad that I can't play planetside 2 or Mechwarrior Online anymore because of their upgrading to 64 bit.

Anyways, thanks for the answers. I'm a long way off from actually making a game (laziness, learning, etc.), but it's nice to know this stuff in advance.

Unfortunately, if the changes they made rely on the 64-bit architecture it won't run on 32-bit systems. In that case they'd really "have to make two different games", as 32-bit processors wouldn't be able to handle the 64-bit dependent processes.