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.