32-bit Windows Builds

This topic is something I forgot to bring up for discussion at the maintainers meeting today.

How important is it to continue supporting 32-bit Windows?

if it was sourceforge hosted it would have public facing download statistics to see how much pull they get. I assume there no easy way to get such things for the gnu ftpmirror downloads?

Correct, there’s no way to get download stats from ftp.gnu.org or mirrors.

(fyi) gnuplot stopped making 32-bit windows releases in 2019.

It is probably save to assume that no halfway modern hardware is running a 32bit Windows OS natively currently.
I’m not sure if we want to take Windows on ARM devices into consideration here. Afaict, that version of Windows (running on Microsoft’s Surface or similar devices by other manufactures) comes with an emulation layer for i686 software. It can’t run x86_64 software.
We aren’t providing a version of Octave that would run natively on Windows on ARM currently. If we stopped providing i686 builds, there wouldn’t be versions of Octave that could be executed on those devices.
While Windows on ARM is actively supported by MS, it is not in very wide-spread use. I don’t know how many users (if any) are actually using Octave on such devices.
If continuing to provide installers for Windows i686 hinders the development in some way, it is probably ok to discontinue supporting these devices.
If it “just” because Windows i686 is “old”, I’d prefer that we could continue providing that version. At least until we can offer an alternative for those devices.

Source: Windows on ARM - UWP applications | Microsoft Docs

1 Like

OK, I don’t object to continuing to provide the 32-bit Windows builds.

1 Like

Maybe deprecate the 32-bits builds? For example, state that Octave-7.x will be the last release with 32-bit builds?


One of the big missing pieces for Windows on ARM support is the Fortran compiler: Flang is still at its infancy, so there are no clang32/clang64 builds of Octave on msys2. Once those are working well for most/all msys2 packages, my guess clangarm64 is in the plan next and it should be possible for the MXE installer to follow suit, no?

Might not be very recent news. But MS gave an update on x64 emulation on Windows on ARM:
Introducing x64 emulation in preview for Windows 10 on ARM PCs to the Windows Insider Program | Windows Insider Blog

Updated 11/16/2021: x64 emulation for Windows is now generally available in Windows 11. For those interested in experiencing this, a PC running Windows 11 on Arm is required.

So, it won’t come for Windows 10 on ARM. But x64 emulation is available now for Windows 11 on ARM.

I agree with @PhilipN that it might make sense to announce that Octave 7 will be the last release for which we’ll provide installers for Windows 32-bit. Users that still need to get a 32-bit version could potentially install the version packaged in MSYS2/MINGW32 for newer versions. (At least, until they drop support for 32-bit as well…)

In the (very) long run, I agree with @kmilos that it might make sense to start packaging Octave for Windows on ARM 64-bit.
Currently, having no Fortran compiler for that platform is a hard blocker. Almost as hard a blocker imho is that we don’t have any CI/testers for that platform. I wouldn’t be comfortable distributing an installer that we never ever started anywhere…

1 Like

Currently, having no Fortran compiler for that platform is a hard blocker

Long ago, when I still ran OS/2, there was an Octave build (based on the EMX emulator) for which all Fortran libraries had first been converted to C using f2c and then built using the EMX c compiler. (IIRC it was Octave-3.0; somewhere around 2005.)
At that time OS/2 was the platform on which Octave ran the fastest (benchmarked and all on my triple-boot Linux & Windows & OS/2 box). I think one reason was that way back then the OS/2 kernel had a superior threading model over Linux and Windows (NT) kernels - at its time OS/2 was the fastest OS I’ve been using anyway.
But more importantly for our case at hand, the fact that the f2c-converted libs apparently didn’t significantly affect performance was remarkable and reassuring.
But honestly I don’t know how much work it would be to do the same trick here. Nor if it is still possible at all.

Again I think we’d better just drop 32-bit builds starting with Octave-8.x. Our developer basis seems too meager to be able to support Octave for a great many HW and OS combinations, let alone legacy OS-es.

1 Like

@PhilipN: Thanks for that information. It might be helpful for anyone interested on that platform who would like to get started on a native build. Some of Octave’s “hard” dependencies are also coded in Fortran. But it might be possible to find (older) versions that only use Fortran 77 syntax that f2c can translate…
Regarding a Fortran compiler for that target, we’d probably need to wait for the flang team of the LLVM developers. Afaict, GCC doesn’t target that platform at all. And I don’t know if there are any plans to do so in the foreseeable future.
IIUC, the LLVM developers plan to ship a flang compiler that is able to output binaries itself with LLVM 15 or 16. I don’t know if it will work on Windows in the very first version(s) though…

Edit: Just to clarify: With “that platform”, I meant Windows on ARM.

Just to make things clear, I merely wanted to point out that a missing Fortran compiler by itself doesn’t necessarily constitute a showstopper for building whatever-bitwidth Octave on any platform.

I hope you don’t mean “OS/2” when you refer to “that platform” - as for me I’ve left it way behind me :slightly_smiling_face: )