4 ms·

Yes, and it's good that it is supported for running old apps. But IMHO there is little reason to build new Windows apps as 32-bit executables.

layer8 1y ago
It’s friendly to users running older or LTSC versions (officially supported until 2032) on older hardware and/or in resource-constrained environments (RAM, power efficiency). There’s a large class of programs who are perfectly fine with 2 GB or less.
jeroenhd 1y ago
Though I don't expect Windows targeting tools to leverage it much, using 32 bit pointers can be quite an efficient method to save memory when keeping track of lots of small objects. You're limited by 4GiB of memory per process, of course, but by switching to 32 bit you're practically halving the space spent on pointers. Using smaller pointers also allows for better data locality and better cache efficiency depending on your data layout. If you're not close to hitting 4GiB of RAM, a few free percentage points in performance aren't a bad deal. Microsoft isn't going to deprecate 32 bit application support any time soon, so you may as well take advantage. That said, so few people have need for it that the deprecation into tier 2 support is probably the right choice. Whatever the 32 bit ABI can do, a custom allocator can probably do just as well on x64. Oh, and Office stll comes in 32 bit mode for some reason. If you're building an Office plugin, you may need 32 bit code.
- flohofwoe 1y ago
  The upside is 32-bit pointers, but the downside is the small register set of x86. Best would be 64-bit ISA with 32-bit pointers, but I don't know if Windows supports such a mode.
  - kelnos 1y ago
    That mode is called "x32", and Windows doesn't support it. Linux does, but it's not particularly popular, and I believe many distros that used to support it have dropped such support.

4 ms·

Yes, and it's good that it is supported for running old apps. But IMHO there is little reason to build new Windows apps as 32-bit executables.

by flohofwoe 1y ago

layer8 1y ago
It’s friendly to users running older or LTSC versions (officially supported until 2032) on older hardware and/or in resource-constrained environments (RAM, power efficiency). There’s a large class of programs who are perfectly fine with 2 GB or less.
jeroenhd 1y ago
Though I don't expect Windows targeting tools to leverage it much, using 32 bit pointers can be quite an efficient method to save memory when keeping track of lots of small objects. You're limited by 4GiB of memory per process, of course, but by switching to 32 bit you're practically halving the space spent on pointers. Using smaller pointers also allows for better data locality and better cache efficiency depending on your data layout. If you're not close to hitting 4GiB of RAM, a few free percentage points in performance aren't a bad deal. Microsoft isn't going to deprecate 32 bit application support any time soon, so you may as well take advantage. That said, so few people have need for it that the deprecation into tier 2 support is probably the right choice. Whatever the 32 bit ABI can do, a custom allocator can probably do just as well on x64. Oh, and Office stll comes in 32 bit mode for some reason. If you're building an Office plugin, you may need 32 bit code.
- flohofwoe 1y ago
  The upside is 32-bit pointers, but the downside is the small register set of x86. Best would be 64-bit ISA with 32-bit pointers, but I don't know if Windows supports such a mode.
  - kelnos 1y ago
    That mode is called "x32", and Windows doesn't support it. Linux does, but it's not particularly popular, and I believe many distros that used to support it have dropped such support.