Remove delay-binding for Win XP and Vista

[sivadeilra]

The minimum supported Windows version is now Windows 7. Windows XP
and Windows Vista are no longer supported; both are already broken, and
require extra steps to use.

This commit removes the delayed-binding support for Windows API
functions that are present on all supported Windows targets. This has
several benefits: Removes needless complexity. Removes a load and
dynamic call on hot paths in mutex acquire / release. This may have
performance benefits.

• "Drop official support for Windows XP"
  Drop official support for Windows XP compiler-team#378

• "Firefox has ended support for Windows XP and Vista"
  https://support.mozilla.org/en-US/kb/end-support-windows-xp-and-vista

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[sivadeilra]

Tagging @rylev @joshtriplett

[Mark-Simulacrum]

r? @joshtriplett - I don't think I can review this, but feel free to reassign of course.

[sivadeilra]

@joshtriplett Ok. Just tagged you because Ryan said that you had been part of the discussions on target platform support / tiers.

[jyn514]

@sivadeilra Mark-simulacrum and joshtriplett are different people :P

[joshtriplett]

Looks reasonable to me. r=me as soon as @rylev confirms.

[12101111]

Typo:

Windows XP and Windows 7 are no longer supported

should be vista not 7

[rylev]

Looks fine to me though I'm not familiar with the APIs in question to give a definitive review. Perhaps @m-ou-se could take a look as she's made several changes in this area lately.

[m-ou-se]

Looks good to me.

A few small comments:

[sivadeilra]

Thanks, @m-ou-se. I've updated with feedback, merged & rebased, and pushed an update.

[m-ou-se]

@bors r=joshtriplett,m-ou-se

[bors]

📌 Commit 59855e0 has been approved by joshtriplett,m-ou-se

[bors]

⌛ Testing commit 59855e0 with merge 9a9477f...

[bors]

☀️ Test successful - checks-actions
Approved by: joshtriplett,m-ou-se
Pushing 9a9477f to master...

[rust-highfive]

📣 Toolstate changed by #81250!

Tested on commit 9a9477f.
Direct link to PR: #81250

💔 miri on windows: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).

[sivadeilra]

I'll take a look at the miri break.

[RandomInsano]

I'd like to revert this change if possible.

I'm curious if this actually improved performance. I have no practical need for XP but it's now broken. Who are the Tier 3 "target maintainers"? It's a little confusing since "i686-pc-windows-msvc" and "x86_64-pc-windows-msvc" are all listed as tier 1 (Windows 7+) and as tier 3 (32/64-bit Windows XP). I'd also like to know if we should think about this change in context with the "i586-pc-windows-msvc" tier 2 as I don't see a need to build a non-SSE version of the standard library

If performance actually did empirically improve I'd be inclined to do what Rust does best here and optimize the choice of API calls at compile time. CPUs are pretty smart these days so I'd feel better if there is test ouptut to back up this change.

If reverting isn't possible, I propose introducing an "msvclegacy" triple to replace "i586-pc-windows-msvc", "x86_64-pc-windows-msvc", and "i586-pc-windows-msvc" because those Tier 3 target names are contradicting with Tier 1. These new triples would also be the proper target for even older efforts such as the one by @seritools.

I'm happy to create a ticket if a new set of triples is the right path. I'm also happy to revert the docs to show that no_std is the only choice for the older targets.

[ChrisDenton]

I'm also happy to revert the docs to show that no_std is the only choice for the older targets.

I think this would be the right thing to do. The Rust std does not officially support Windows versions before Windows 7. Even when it did, it was broken in various other ways due to lack of maintainers and testing (which is a big part of why it's no longer supported). Reverting this PR wouldn't be enough to support XP.

If there are people willing to commit to maintaining a new XP (or even 9x) target then I'd personally very much welcome them. They would need to follow the new target tier process you linked to or else maintain their own fork.

[seritools]

For now I also see old windows support as something a fork would be better suited to as there are lots and lots of small and big limitations, depending on how far "down" in Windows support you dare to go.

@RandomInsano since I know you're interested, this was my list of notes and known limitations for rust9x back from when I had the time to work on it :^)

Details

Notes

• Note that the default target-cpu for i686 targets is pentium4 (enabling SSE2). You may want to set a lower target cpu like pentiumpro.

• SafeSEH is only enabled if linked with modern libraries

• Backtraces are fully disabled for now

• The modern VC2019 linker does not like linking against the dynamic VC6 CRT MSVCRT.LIB and just
  hangs instead. Switching to target-feature=+crt-static making it link against LIBCMT.LIB
  instead works, however. If you'd like to link against the dynamic CRT, use the VC8 (VS 2005)
  linker instead.

Fallback limitations

A lot of APIs have limitations on older systems - refer to old MSDN Libraries (e.g. from VS 2005)
and KB articles for more information

• std::process::Child::id() returns the process handle as DWORD on systems that don't support
  GetProcessId

• std::fs::canonicalize uses GetFinalPathNameByHandleW and will Err on systems before
  Vista/Server 2008.

• std::fs::soft_link uses CreateSymbolicLinkW and will Err on systems before Vista/Server
  2008.

• std::fs::hard_link uses CreateHardLinkW and will Err on systems before Windows 2000.

• std::fs::File::set_permissions will Err on systems before Vista/Server 2008.

  • this needs SetFileInformationByHandle. You may be able to get it working on XP/Server 2003
    with some fileextd.lib shenanigans

• HashMap initialization: If RtlGenRandom/SystemFunction036 (>= XP/Server 2003) is not
  available, the two seed u64s are filled with data from GetTickCount, GetSystemTimeAsFileTime
  and GetCurrentProcessId. This is not random data!

• Socket handles are inherited on NT versions before 3.51, as neither
  WSA_FLAG_NO_HANDLE_INHERIT nor SetHandleInformation are supported.

  On 9X/ME, socket handles are non-inheritable by
  default.

  • As WinSock 2 is not supported on NT 3.51 and below anyways this shouldn't be a problem for now

• FileExt::seek_read and FileExt::seek_write are not supported on 9X/ME, as these systems do not support overlapped I/O for files.

• FreeEnvironmentStringsW doesn't exist on NT 3.1, so env::vars and env::vars_os leak the OS-allocated buffers.

Synchronization primitives

Mutex, CondVar and RwLock have fallback implementations for every windows version.

• Mutex: SRWLocks (Win 7+), Critical Sections (NT4+), CreateMutex (all)
• CondVar: CondVarSRW (Win 7+), CreateEvent (all)
  • Limitation: the CondVar fallback impl always wakes up all waiting threads
• RwLock: SRWLocks (Win 7+), Mutex (all; based on mutex impl above)
  • Limitation: fallback impl does not actually allow mutliple readers at the same time, so there is no performance benefit over a Mutex

Default allocator on 9x/ME

From old MSDN:

Windows Me/98/95: The heap managers are designed for memory blocks smaller than four
megabytes. If you expect your memory blocks to be larger than one or two megabytes, you can avoid
significant performance degradation by using the VirtualAlloc or VirtualAllocEx function
instead.

It might make sense to use an alternative allocator instead.

[RandomInsano]

Sounds good. Considering the additional pieces that failed to work before, I think the fork is the right approach for now. I’ll open that PR for changing the docs now.

…

On Mar 1, 2022, at 2:22 PM, Dennis Duda ***@***.***> wrote:  For now I also see old windows support as something a fork would be better suited to as there are lots and lots of small and big limitations, depending on how far "down" in Windows support you dare to go. @RandomInsano since I know you're interested, this was my list of notes and known limitations for rust9x back from when I had the time to work on it :^) Details — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.