So they have. Though I doubt the utility of creating the 32 bit configuration because I don't see anyone creating 32 bit x86 Windows Desktop applications any time soon. They're more likely to create arm64 than x86.

As for changing properties in MSVC, the issue I had was that when creating a new solution it would create a x86 project by default. So I would have to go in and create a new x64 configuration, change the project properties for all projects, then remove the x86 configuration from the projects and solution. Though whenever I added a new project it would default to x86 and I would have to redo all of the configuration steps again and once more delete the x86 configuration from the solution. I even tried using props files to try and simplify this but it never worked well enough.

So for me it was much easier to learn how to use CMake properly, add the global settings to the top level CMakeLists.txt file, then a new project could be added by creating a new CMakeLists.txt file and rerunning CMake. There would be no need to mess around with the settings in the IDE worrying about if you forgot to update one or if the settings got out of sync.

For simpler applications, 32 bit will use less RAM without any noticeable disadvantages, so it's not the worst default in the world. Kind of questionable, perhaps. It does mean your software will work on older PCs, though!

32 bit mode has fewer registers and CPU extensions to use. On Linux there are experiments with an ABI with 32 bit pointers, but otherwise using the full feature set of AMD64, it's called the x32 ABI.

https://en.wikipedia.org/wiki/X32_ABI

And it works so well! I remember doing some particle rendering and tree walking benchmark on it and it was really really faster, like 15% consistently

Interesting! I'm actually tempted to put x32 Debian on a low-end netbook I have. I wonder if it's possible with multiarch and try with a few apps first.

Might get removed in the future [0], though!

[0] https://lwn.net/Articles/774734/

Ah, too bad. I wonder why it needs a distinct Linux syscall interface though. There must be a reason why the existing x86_64 or x86 syscalls could not be used for x32.

To target older PCs you also need to target something like Windows 7 rather than Windows 10 or later.

It also depends how you write your code because there are many ways to reduce memory usage, for example switching to arrays and 32bit indexes instead of using native sized pointers. Can also use smaller data types than size_t etc.

Having both x64 and x86 as configurations by default is a step forward, but realistically I wouldn't want any configuration in my solution which does not work and is not supported.