Having slept on this, and also reading all of the replies (thanks!), some other thoughts.
Nothing changes my thinking in my original post - Windows 32-bit compilation being removed will be more than just a minor annoyance.
Yes, I can keep 2 versions of Xojo around, one for building MacOS and the other for building Windows. But there are some serious inconveniences and other issues with doing this. (I’m building both Mac and Windows versions from the Mac only, never from the Windows IDE, and cross-debug onto Windows when necessary).
Instead of being able to do a single build for both platforms, with the same project loaded (and the same with debugging) in whatever Xojo version ID is the “standard” you’re using (maybe the most current, maybe not, depending on other factors), you’d need to quit one IDE and launch the other and reload everything. (I’m not thinking it’s realistic to keep 2 versions of the IDE running and hooked into the same source files just to do this, due to the memory footprint and other considerations). So this is, at best, awkward and time consuming.
Then, you’re building product(s) with different revs of the language itself, with Windows builds behind held back to the last 32-bit-buildingn rev, and Mac builds moving onward. This introduces more potential chaos and uncertainty in your code, development, and debugging because now “both things” are never going to be really the same. Taking advantage of new language features added in Xojo revs that don’t support building 32-bit Windows? You wouldn’t want to do this. There are already enough potential platform-specific conditionally compiled things you may need in your code, to take into account platform differences, even if a single rev of Xojo is being used to build both platforms. Having Windows x86 builds frozen at a certain rev of the IDE and language makes that even worse.
As others have noted, Windows 32-bit continues to be used and is not going away any time soon, regardless of Microsoft plowing on ahead slowly with Windows 11 (64-bit only, but of course fully capable of running x86 software) and eventually deprecating their own support for 32-bit. This doesn’t affect the universe of 32-bit installations still in use, in any kind of short or medium term timeframe.
As I said, moving software builds to 64-bit only, even in the case of “this is easy, I’ll just rebuild my target for 64 bit and it’ll just work”, is problematic, since those 64-bit builds are then fully incompatible with the sub-universe of Windows 32-bit systems still in existence. You can’t make a 64-bit build that could be used by all of your customers, without requiring THEM to be running 64-bit Windows. (on older systems, physically not possible; even on newer systems, they may have simply installed Windows 10 32-bit and there’s no way to simply update those systems to 64-bit, and even if there was, other factors may prevent them from doing that). And that’s the “easy” case where there aren’t any issues rebuilding your own software other than a simple recompile to a 64-bit target. If you have 32-bit non-Xojo components of your own (either homegrown or from other outside sources), you’re either out of luck (the latter) or potentially in for a lot of additional work and testing (the former).
Then there are Windows installers and related issues. InstallShield, for example, doesn’t let you make a single installer for both 32 and 64-bit software. You end up with even more complications; maybe you want to still build 32-bit for older systems and 64-bit for the rest, that support it. Then, you’re left with not only building from 2 different Xojo IDEs, but creating 2 separate installers, each for a different flavor of the Windows product).
There are 2 simple solutions to all of this, from a developer perspective.
-
Xojo keeps Windows 32-bit compilation around. Developer happy.
-
Xojo fully removes Windows 32-bit compilation in a future rev. Developer unhappy. Developer either has to “never” move up to later versions of Xojo, and stays stuck at the last rev to support Windows 32-bit; or has to figure out the best way to deal with all of the repercussions above, none of which are ideal in any way.
TLDR: ARGH.