Rethink supporting Windows XP

[liigo]

I've made some investigation recently, and found that, there are only two APIs which are not supported by Windows XP, throughout the repo tree. There are:

• CreateSymbolicLinkW, only used by native::io::file::symlink()
• GetFinalPathNameByHandleW, only used by native::io::file::readlink()

And native::io::file::{symlink,readlink} are never used throughout the repo tree, except std::io::fs::{symlink,readlink} (which are really never used).

Do we really need including symlink/readlink functionality inside std? How other languages do?

Currently Windows XP is still wildly used in the world, especially in Asia. Its installed volume is much more than Mac OS + Linux + Unix. We give up supporting XP just because of two api absent? Maybe it's wrong.

cc #11950

update: readlink is used by rustc::metadata::filesearch.

update: This is my branch: https://github.com/liigo/rust/tree/xp
I just commented out the usage of CreateSymbolicLinkW and GetFinalPathNameByHandleW. This make the new rustc.exe run successfully in Windows XP, ant it works mostly OK (see my latest comment below).

[huonw]

I thought there were mutex and condition variable APIs that are not supported on windows XP too?

[liigo]

@huonw After remove CreateSymbolicLinkW and GetFinalPathNameByHandleW, I've made rustc run in XP (it works ok). More investigation need to be done perhaps.

[huonw]

Oh, really? Does it pass tests?

(cc #11950 )

[liigo]

I don't know. On Windows platform (even Win7), make check always fails. see #12745

[huonw]

make check-fast or even just make check-stage2-std should pass (at least, they pass on the buildbots).

[liigo]

I'll have a try. Thank you! @huonw

In general, a .exe can't be start up, if it includes unsupported APIs in Import Table. Before i remove CreateSymbolicLinkW and GetFinalPathNameByHandleW from source, rustc can't be start up in XP; after removing, the new rustc runs normally. So I think, rustc doesn't require other unsupported API. Will prove it.

Update: my new rustc.exe can be loaded successfully by depends.exe in XP. Yes, It has no other dependency.

[liigo]

@huonw
make check-fast:

run-pass [stage2]: test\run-pass\exponential-notation.rs
task '<main>' failed at 'called `Option::unwrap()` on a `None` value', D:\MinGW\msys\1.0\home\LIIGO\rust\rust\src\libstd
\option.rs:148
make: *** [i686-pc-mingw32/test/run_pass_stage2_driver-i686-pc-mingw32.out] Error 101

(This is not my fault, IMO)

make check-stage2-std: All tests passed. (update: Runs in Win7, sorry!)

This is my branch: https://github.com/liigo/rust/tree/xp
I just commented out the usage of CreateSymbolicLinkW and GetFinalPathNameByHandleW.

[bharrisau]

Might be an issue with UTF8 or floating point arithmetic on XP?
https://github.com/mozilla/rust/blob/master/src/libstd/num/strconv.rs#471

[liigo]

@bharrisau Are you sure?

I've compiled the std and its tests from source in Windows XP using my new rustc.exe. Compiled OK, most tests passed, and some tests failed (1276 passed; 41 failed; 134 ignored):

(Looks like all failures are from libgreen and libnative. But I don't know why currently.)

failures:

---- io::net::tcp::test::multiple_connect_serial_ip6::green stdout ----
    task 'io::net::tcp::test::multiple_connect_serial_ip6::green' failed at 'called `Result::unwrap()` on an `Err` value', src\libstd\result.rs:187

---- io::net::tcp::test::multiple_connect_serial_ip6::native stdout ----
    task 'io::net::tcp::test::multiple_connect_serial_ip6::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::net::tcp::test::read_eof_twice_ip6::green stdout ----
    task 'io::net::tcp::test::read_eof_twice_ip6::green' failed at 'unknown kind: OtherIoError', src\libstd\io\net\tcp.rs:294

---- io::net::tcp::test::read_eof_twice_ip6::native stdout ----
    task 'io::net::tcp::test::read_eof_twice_ip6::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::net::tcp::test::smoke_test_ip6::green stdout ----
    task 'io::net::tcp::test::smoke_test_ip6::green' failed at 'called `Result::unwrap()` on an `Err` value', src\libstd\result.rs:187

---- io::net::tcp::test::smoke_test_ip6::native stdout ----
    task 'io::net::tcp::test::smoke_test_ip6::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::net::tcp::test::socket_and_peer_name_ip6::green stdout ----
    task 'io::net::tcp::test::socket_and_peer_name_ip6::green' failed at 'called `Result::unwrap()` on an `Err` value', src\libstd\result.rs:187

---- io::net::tcp::test::socket_and_peer_name_ip6::native stdout ----
    task 'io::net::tcp::test::socket_and_peer_name_ip6::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::net::tcp::test::tcp_clone_two_read::green stdout ----
    task 'io::net::tcp::test::tcp_clone_two_read::green' failed at 'called `Result::unwrap()` on an `Err` value', src\libstd\result.rs:187

---- io::net::tcp::test::tcp_clone_two_read::native stdout ----
    task 'io::net::tcp::test::tcp_clone_two_read::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::net::tcp::test::write_close_ip6::green stdout ----
    task 'io::net::tcp::test::write_close_ip6::green' failed at 'unknown error: io::IoError{kind: OtherIoError, desc: "address family not supported", detail: None}', src\libstd\io\net\tcp.rs:348

---- io::net::tcp::test::write_close_ip6::native stdout ----
    task 'io::net::tcp::test::write_close_ip6::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::net::udp::test::socket_name_ip6::green stdout ----
    task 'io::net::udp::test::socket_name_ip6::green' failed at 'assertion failed: server.is_ok()', src\libstd\io\net\udp.rs:253

---- io::net::udp::test::socket_name_ip6::native stdout ----
    task 'io::net::udp::test::socket_name_ip6::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::net::udp::test::socket_smoke_test_ip6::green stdout ----
    task 'io::net::udp::test::socket_smoke_test_ip6::green' failed at 'explicit failure', src\libstd\io\net\udp.rs:142

---- io::net::udp::test::socket_smoke_test_ip6::native stdout ----
    task 'io::net::udp::test::socket_smoke_test_ip6::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::net::udp::test::stream_smoke_test_ip6::green stdout ----
    task 'io::net::udp::test::stream_smoke_test_ip6::green' failed at 'explicit failure', src\libstd\io\net\udp.rs:212

---- io::net::udp::test::stream_smoke_test_ip6::native stdout ----
    task 'io::net::udp::test::stream_smoke_test_ip6::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::process::tests::detach_works::green stdout ----
    task 'io::process::tests::detach_works::green' failed at 'called `Result::unwrap()` on an `Err` value', src\libstd\result.rs:187

---- io::process::tests::exit_reported_right::green stdout ----
    task 'io::process::tests::exit_reported_right::green' failed at 'assertion failed: p.is_ok()', src\libstd\io\process.rs:454

---- io::process::tests::detach_works::native stdout ----
    task 'io::process::tests::detach_works::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::process::tests::smoke::green stdout ----
    task 'io::process::tests::smoke::green' failed at 'assertion failed: p.is_ok()', src\libstd\io\process.rs:430

---- io::process::tests::exit_reported_right::native stdout ----
    task 'io::process::tests::exit_reported_right::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::process::tests::smoke::native stdout ----
    task 'io::process::tests::smoke::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::process::tests::stdout_works::green stdout ----
    task 'io::process::tests::stdout_works::green' failed at 'assertion failed: p.is_ok()', src\libstd\io\process.rs:487

---- io::process::tests::stdout_works::native stdout ----
    task 'io::process::tests::stdout_works::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::process::tests::test_finish_once::green stdout ----
    task 'io::process::tests::test_finish_once::green' failed at 'called `Result::unwrap()` on an `Err` value', src\libstd\result.rs:187

---- io::process::tests::test_finish_once::native stdout ----
    task 'io::process::tests::test_finish_once::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::process::tests::test_finish_twice::green stdout ----
    task 'io::process::tests::test_finish_twice::green' failed at 'called `Result::unwrap()` on an `Err` value', src\libstd\result.rs:187

---- io::process::tests::test_finish_twice::native stdout ----
    task 'io::process::tests::test_finish_twice::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::process::tests::test_process_output_error::green stdout ----
    task 'io::process::tests::test_process_output_error::green' failed at 'called `Result::unwrap()` on an `Err` value', src\libstd\result.rs:187

---- io::process::tests::test_process_output_error::native stdout ----
    task 'io::process::tests::test_process_output_error::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::process::tests::test_kill::native stdout ----
    task 'io::process::tests::test_kill::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::process::tests::test_process_output_output::green stdout ----
    task 'io::process::tests::test_process_output_output::green' failed at 'called `Result::unwrap()` on an `Err` value', src\libstd\result.rs:187

---- io::process::tests::test_process_output_output::native stdout ----
    task 'io::process::tests::test_process_output_output::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::process::tests::test_process_status::green stdout ----
    task 'io::process::tests::test_process_status::green' failed at 'called `Result::unwrap()` on an `Err` value', src\libstd\result.rs:187

---- io::process::tests::test_wait_with_output_once::green stdout ----
    task 'io::process::tests::test_wait_with_output_once::green' failed at 'called `Result::unwrap()` on an `Err` value', src\libstd\result.rs:187

---- io::process::tests::test_wait_with_output_once::native stdout ----
    task 'io::process::tests::test_wait_with_output_once::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::process::tests::test_wait_with_output_twice::green stdout ----
    task 'io::process::tests::test_wait_with_output_twice::green' failed at 'called `Result::unwrap()` on an `Err` value', src\libstd\result.rs:187

---- io::process::tests::test_process_status::native stdout ----
    task 'io::process::tests::test_process_status::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

---- io::process::tests::test_wait_with_output_twice::native stdout ----
    task 'io::process::tests::test_wait_with_output_twice::native' failed at 'receiving on a closed channel', src\libstd\comm\mod.rs:507

test result: FAILED. 1276 passed; 41 failed; 134 ignored; 0 measured

[bharrisau]

I just looked at that test you failed for uses of Option.unwrap. Was trying
to suggest why the test was failing even though you didn't change anything.

[liigo]

Thank you!
2014年3月12日 下午8:53于 "Ben Harris" notifications@github.com写道：

I just looked at that test you failed for uses of Option.unwrap. Was trying
to suggest why the test was failing even though you didn't change
anything.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12842#issuecomment-37404548
.

[thestinger]

@huonw: Rust doesn't expose native condition variables yet. When it does, that's another API that's missing on XP. I don't think Rust should support an operating system not receiving security updates because encouraging any continued use of it is irresponsible. I don't think we should add a further burden to working on the concurrency and I/O implementation. It's already very hard to improve because libuv defines a lowest common denominator it needs to support, and XP would be another.

[liigo]

@thestinger I disagree with you. C, C++, Java, C#, Python, Ruby, Scala, and many more, all support Windows XP.

[bharrisau]

Without knowing much about it, it doesn't look too onerous to take some functions out of the extern block and replace them with a dl::symbol call and checking for null.

Probably worth writing up an RFC if you want XP to be supported properly. It will end up with lots of fail!("feature X is not supported before Windows 7").

[eddyb]

@thestinger +1
@liigo most of those don't claim any sort of safety guarantees, some are laughably worse than others (I'm looking at you, Java) and I don't expect any of them (maybe Scala?) to have condition variables in core libraries.
@bharrisau runtime failure based on feature set is unacceptable, at worst I'd expect to see two different OSes for Windows, windows-xp having features disabled in libraries via #[cfg] (and lowering the minimum API level somewhere, I know there is such a thing on Windows).

[thestinger]

Supporting Windows XP means Rust will need a homegrown implementation of condition variable, among other problems. It won't be possible for it to be included in the generic Windows target without performance hits because branches + bloated code aren't always acceptable.

I think it's unethical to care about usage share to the point where users are encouraged to remain on an insecure platform without security updates. If Apple or Microsoft isn't providing support, then we shouldn't be providing support. It gives us a nice gradual deprecation policy where we can actually migrate to new win32 APIs, etc. but I think the more important issue is the security one.

To be honest, I can't really think of a use case for an XP target beyond malware development. It's not like XP users are going to buy your products or consider open-source software.

[Thiez]

To be honest, I can't really think of a use case for an XP target beyond malware development.

Lucky for the malware developers, I imagine #[no_std] will allow them to write safe concurrent malware in rust for windows xp.

[Aatch]

I agree with @thestinger, Windows XP is about to reach the end of it's already significantly extended support lifetime, and has been without mainstream support for almost 5 years now. Bending over backwards for it is just not worth it.

At the age of 13, XP is stupidly old. If there are small, unobtrusive changes you can make so rustc still works on XP, then fine, but official support doesn't make sense. We don't even list BSD as an officially supported build environment, and that's an actively-developed OS!

[adrientetar]

I +1 the drop of XP. It is like using IE6 polyfills when doing web developement, not only you do have to include more hacks to support it but it is also making users believe they have a viable platform. Which is not the case.

[flaper87]

Although the experiment of making it run on XP may be fun (?) I don't think we should add official support for it (again?). @brson @alexcrichton any thoughts about this ?

[esummers]

Although I personally agree that official XP support should be dropped, it may be worth asking some video game developers for their opinions. I'm not a hard core gamer, but I believe there is still a significant number of gamers that use XP due to some performance issues in Windows 7 and 8. Of course by the time Rust is actually used in a commercial game this may have changed. Rust shouldn't do anything that may alienate the video game development crowd.

[brson]

Personally, I am happy to take patches that improve compatibility with xp as long as it doesn't have a big impact on the design. Having a design that is compatible with diverse environments is good for more than just xp. The issues preventing Rust from working on xp appear minor and solvable. I don't want to 'officially' support xp though.

[flaper87]

@brson +1

[thestinger]

@brson: Removing symlink/readlink functionality or leaving out native condition variables (as we currently do) would hurt the quality of the project elsewhere. If XP is going to be supported, it needs a separate target to use in cfg() or at least stubbed out functionality that's conditionally linked against.

[liigo]

Libuv has itself condition variables implementation to Support XP.
2014年3月15日 上午4:11于 "Daniel Micay" notifications@github.com写道：

@brson https://github.com/brson: Removing symlink/readlink
functionality or leaving out native condition variables (as we currently
do) would hurt the quality of the project elsewhere. If XP is going to be
supported, it needs a separate target to use in cfg().

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12842#issuecomment-37690132
.

[thestinger]

I don't think it's acceptable to have a hard dependency on libuv for binaries not using libgreen. It doesn't make sense to add a whole bunch of overhead to support a dead operating system... I doubt that the libuv implementation of condition variables is efficient.

[tshepang]

I understand the word "indefinitely" to mean that there are no plans to drop support for it, instead of "forever".

Note that XP is still a very large market, and is said to have more users than desktop Linux.

[petrochenkov]

@Thiez

XP will follow, it's only a matter of time.

The question is - how much time.
Looking at graphs at netmarketshare.com (and looking around!) I can easily imagine it being quite popular in 2020. In this case the support is probably worth it.

(I was going to look at Vista/XP support later this year, but since @alexcrichton works approximately 100x faster than me, it won't probably be necessary.)

[KostaCitrix]

First of all: Thank you so much for fixing this! This is awesome! 👍

Is there a way to detect at compile time or at application init time whether a panic'ing API would be used? If I have an app that should run on Windows XP, I don't want to have to test every code path to make sure some unsupported API doesn't panic...

Thanks in advance for your consideration! :)

[steveklabnik]

Is there a way to detect at compile time or at application init time whether a panic'ing API would be used?

Not currently, no.

[KostaCitrix]

Is there a way to detect at compile time or at application init time whether a panic'ing API would be used?

Not currently, no.

Is this planned or possible? I think that would be crucial to be able to write code without being "really careful about which APIs to use". If I wanted to be careful, I wouldn't choose Rust ;)

[steveklabnik]

Not currently. You may want to open an issue on the RFCs repo and/or write up an RFC with details on how to do such a thing. :)

[tshepang]

@KostaCitrix I'm not sure I understand this joke:

If I wanted to be careful, I wouldn't choose Rust.

Do you mean Rust is too young?

[KostaCitrix]

If I wanted to be careful, I wouldn't choose Rust.

Do you mean Rust is too young?

I meant "If I wanted to be careful about which API to call in order to not panic, I wouldn't choose Rust". I want my rust to "it compiles, let's ship it" ;)

[anfractuosity]

This sounds really cool!, I'm waiting for the nightly to try out this patch.

When I run my Rust program on WinXP at the moment currently I get 'the procedure entry point TryAcquireSRWLockExclusive could not be located in the dynamic link library kernel32.dll'

With this patch, I'm wondering, will my program likely just panic out, or may it run.

[alexcrichton]

This will take some time to propagate into the nightlies currently. The 32-bit Windows compiler is currently still using MinGW and is unlikely to work on Windows XP (although I have not tested this). The triple I tested was i686-pc-windows-msvc, which we currently cannot build a compiler for due to this LLVM bug. Instead you'd need to build a compiler which can target i686-pc-windows-msvc. We don't currently build nightlies for targets like this either (e.g. we have no android nightlies), but this is also coming soon!

tl;dr; to try out XP support you need to do this:

./configure --build=x86_64-pc-windows-msvc --target=i686-pc-windows-msvc
make
./x86_64-pc-windows-msvc/stage2/bin/rustc.exe foo.rs -C link-args="/subsystem:console,5.01"

[anfractuosity]

Thanks a lot!

I'll give that a shot, I didn't realise it requires a separate target

[anfractuosity]

I'm a tad confused I've ended up with a rustc in the stage2 dir you mention however during compilation I got

cfg: version 1.3.0-dev (216f6645e 2015-06-29)
cfg: build triple x86_64-pc-windows-msvc
cfg: host triples x86_64-pc-windows-msvc
cfg: target triples x86_64-pc-windows-msvc i686-pc-windows-msvc
cfg: non-build target triples i686-pc-windows-msvc
cfg: host for x86_64-pc-windows-msvc is x86_64
cfg: host for i686-pc-windows-msvc is i386
cfg: os for x86_64-pc-windows-msvc is pc-windows-msvc
cfg: os for i686-pc-windows-msvc is pc-windows-msvc
cfg: good valgrind for x86_64-pc-windows-msvc is
cfg: good valgrind for i686-pc-windows-msvc is
cfg: using CC=gcc (CFG_CC)
cfg: disabling valgrind run-pass tests
cfg: no xelatex found, disabling LaTeX docs
cfg: no pandoc found, omitting PDF and EPUB docs
make: *** No rule to make target 'i686-pc-windows-msvc/rt/rust_try_msvc_32.o', needed by 'i686-pc-windows-msvc/rt/rustrt_native.lib'.  Stop.

I've tried doing

 ./rustc --target=i686-pc-windows-msvc foo.rs -C link-args="/subsystem:console,5.01"
foo.rs:1:1: 1:1 error: can't find crate for `std`
foo.rs:1 pub fn main(){
         ^
error: aborting due to previous error

If I omit the target parameter and use

 rustc foo.rs -C link-args="/subsystem:console,5.01" -L  "C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86" -L "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib"

I get

.....
 "ws2_32.lib" "userenv.lib" "advapi32.lib" "kernel32.lib" "shell32.lib" "msvcrt.lib" "/subsystem:console,5.01" "compiler-rt.lib"
note: msvcrt.lib(chkstk.obj) : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'

error: aborting due to previous error

[alexcrichton]

@anfractuosity you probably won't get very far if the build doesn't complete, so I'd start out diagnosing why rust_try_msvc_32.o didn't build. Perhaps a reconfigure was needed?

[alexcrichton]

Oh wow it looks like I just totally forgot to commit the file! I'll add it in a PR I'm prepping now, but you can add src/rt/rust_try_msvc_32.ll with these contents:

define i8* @rust_try(void (i8*)* %f, i8* %env) {
    call void %f(i8* %env)
    ret i8* null
}

[anfractuosity]

Cheers! That works for me.

In msys2 I did, just so I don't forget ;)

 export PATH="C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin":$PATH

./rustc --target=i686-pc-windows-msvc  --verbose foo.rs -C link-args="/subsystem:console,5.01" -L  "C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86" -L "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib"

[anfractuosity]

Just wondering if anyone can point me in the right direction, I can compile a simple rust program fine, but I'm getting the following error with a more complex one:

note:    Creating library C:\Users\chris\Documents\GitHub\hymntoninkasi\target\d
ebug\deps\c_vec-460b36a551b013a2.lib and object C:\Users\chris\Documents\GitHub\
hymntoninkasi\target\debug\deps\c_vec-460b36a551b013a2.exp
LINK : error LNK2001: unresolved external symbol _DllMainCRTStartup
C:\Users\chris\Documents\GitHub\hymntoninkasi\target\debug\deps\c_vec-460b36a551
b013a2.dll : fatal error LNK1120: 1 unresolved externals

[MrAlert]

The MinGW target seems to work for Windows XP. Or at least stdtest-i686-pc-windows-gnu.exe gets this far:

test ascii::tests::test_ascii ... thread '<main>' panicked at 'condition variables not available', src/libstd\sys/windows\c.rs:415
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "PoisonError { inner: .. }"', src/libcore\result.rs:731

Looks like the test infrastructure already relies on condition variables for something.

[anfractuosity]

@MrAlert Was that using the latest nightly build then?

Edit: I see it is, and my GTK application, works with it!

Thanks a lot for your work on this Alex.