CreateSymbolicLinkW (and possibly others) are not supported in Windows XP

[lifthrasiir]

A binary compiled with the recent master (or possibly much older master) and extern mod native; fails to run in Windows XP due to the missing symbols including CreateSymbolicLinkW, which are supported since Windows Vista. I don't have a working Windows XP environment at the moment so there might be more missing symbols. (I've received the report via some user with Windows XP.)

I'm not sure if it is intentional or not, but given that libuv has a check for the support, we at least need to determine whether to fix or not.

[thestinger]

According to the README, we only support Windows 7 and later. I've brought up the subject of whether we support Windows XP a few times and the consensus has been that we will not support it. Support ends on April 8th this year anyway.

[lifthrasiir]

@thestinger I don't think the README, as currently is, explicitly claims that non-"tier 1" platforms are not supported at all. Rather it is more like a different level of support, such that (say) we are willing to support Windows Vista but do not regularly test the master on it. We do not mention such "tier 2" platforms currently, which in my opinion should be made explicit at some point.

As a side note, you said the consensus and the consensus needs to be verified. I couldn't find any explicit decision to drop support for Windows XP in any of rust-dev archives (via Gmane), #rust and #rust-internals archives (via botbot.me) and Github issues. What I could found was as follows:

• In Implement a native mutex type #10479 and Native comm tests are disabled on Windows #11003, @alexcrichton seems to know nothing about the decision.
• In mutexes should be separate from condition variables #10574 and several conversations on IRC, you (@thestinger) are strongly against the support for Windows XP due to the lack of native condition variables.
• rustc is slow on Windows XP #4303 (2012-12) and Failure on non-ASCII path on windows #9618 are created by users that are using Windows XP at least sparingly.
• In the rust-dev archives for the past year, there seems to be at least one person that uses Windows XP.
• Botbot.me search on #rust also shows handful people using Windows XP (2014-01-20, 2014-01-05, 2013-08-07, 2013-07-11 to name a few).
• In IRC, @brson said he personally does not care about XP but noted that Firefox still supports it and XP is still widely used in Asia. Also @cmr points out that XP still has 6.17% share on Steam.

In light of this finding, I cannot say that there was a consensus at all. There are good reasons to support Windows XP (it will be around for some more years anyway) or not to support it (hurts the performance on newer platforms unless carefully engineered), but they are not the consensus.

Edit: Okay, I forgot to search the meetings and I think I've found some mention of the existence of "tier 2" platforms (and the fact that it includes Windows XP at the least).

[thestinger]

If you really want to add support for XP and drop it on April 8th, then we this can be a meeting issue again.

[lifthrasiir]

I think you misunderstood my comments. If "tier 2" platforms include Windows XP, then this issue should not be closed (but will be of low priority) no matter it hit the EOL or not. And 2014-04-08 is not the final EOL of Windows XP anyway (Windows XP Embedded receives the extended support til 2016-01-12).

[thestinger]

So if someone submits a pull request moving to a new Win32 API not available on XP, should it be rejected or accepted? There's a clear distinction between supporting it and not supporting it, regardless of a tier categorization.

[lifthrasiir]

That is the explicit consensus, which I believe (but am not very sure) that it's to reject such PR.

[zr40]

I, for one, would not want an ancient and almost unsupported OS such as Windows XP to dictate the lowest common denominator of acceptable API usage.

[adrientetar]

@lifthrasiir Windows XP Embedded is not for Personal Computers.

[brson]

We can take patches to support XP, we just don't intend to make any promises about it, and supporting it shouldn't hinder design decisions. What are we relying on symbolic linking in windows for?

[pnkfelix]

Assigning P-low, not 1.0 blocker