Rust on Windows Vista (crash with SetThreadErrorMode)

[techtonik]

rust-1.10.0-i686-pc-windows-gnu.msi contains compiler that doesn't run on Vista - crashes with missing SetThreadErrorMode in KERNEL32.dll. I thought that I can use Rust as a platform independent C replacement, but it seems not possible. Maybe there are binaries without those Windows 10 specific optimizations that I missed?

[nagisa]

The compiler itself requires at least Window 7 (Windows Server 2008 R2) to run. Programs compiled with Rust may run with Windows all the way back to XP, but some features exposed by the standard library (most notably locking) will not work.

[techtonik]

@nagisa is it possible to to use software emulation for missing features on development machines? It will help to save the day. Also, can Rust detect and warn when such feature would be missing on target platform and compiled program won't run?

[petrochenkov]

@techtonik

is it possible to to use software emulation for missing features on development machines?

Sure, there's an issue about this: #26654
Unfortunately no one had enough motivation to implement the emulation so far.
There were attempts though - #27036, you can try to resurrect that PR if you need XP/Vista support.
RFC 1632 (rust-lang/rfcs#1632) worked the problem around by not using Windows API calls at all for synchronization primitives, but it was rejected.

[nagisa]

is it possible to to use software emulation for missing features on development machines?

It would certainly be possible to switch out our use of SetThreadErrorMode with SetErrorMode, but I’m pretty sure there’s more cases like this, many of which are not as trivially solved.

Also, can Rust detect and warn when such feature would be missing on target platform and compiled program won't run?

Everything is possible, but not necessarily feasible. At the moment targetting Windows does not differentiate between you targetting Windows XP and Windows 10. Compiled code is the same. A number of user facing changes would be necessary to implement something like that and we’ve very consciously claimed only Tier 3 support for libstd only on XP.

[retep998]

@nagisa Choosing which version of Windows you want to target could actually be done by telling winapi which version you want, and then it informs downstream dependencies of that choice rust-lang/cargo#2980. Of course it doesn't work too well for std at the moment but in a future where something like rust-lang/rfcs#1133 has been implemented it could even cover that.

[techtonik]

It would certainly be possible to switch out our use of SetThreadErrorMode with SetErrorMode, but I’m pretty sure there’s more cases like this, many of which are not as trivially solved.

Is there any attempt to collect and document those issues for learning and making consensus?

[Amanieu]

The problem here is that it's LLVM that requires at least Windows 7 to run, rather than the Rust compiler itself.

Note that this only applies to rustc: most Rust programs will run fine on Windows XP and above (barring some issues with locking, which is a separate issue).

[techtonik]

So is there an issue in LLVM that can be referenced from here?

[Amanieu]

Not that I know of. Dropping support for older versions of Windows was an explicit decision from the LLVM developers. See http://llvm.org/releases/3.8.1/docs/ReleaseNotes.html.

[Mark-Simulacrum]

I don't believe there's anything we can do about this, but I may be wrong. Perhaps @retep998 could comment? I feel like we should close this...

[retep998]

If LLVM has decided to not support running on Windows Vista, then there is nothing we can do here. If rustc ever supports an alternate backend that does support Windows Vista, then this can be reconsidered then.