std's tests fail to dynamically link under Windows 7 due to `GetHostNameW` missing

[PaulDance]

When running std's tests under Windows 7, it fails on the first execution on the following error:

     Running unittests lib.rs (build/x86_64-unknown-linux-gnu/stage1-std/x86_64-win7-windows-msvc/release/deps/alloctests-6f6372787480eb2d.exe)
uploaded "/builds/hlab/rust-ci/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-win7-windows-msvc/release/deps/alloctests-6f6372787480eb2d.exe", waiting for result
run "C:\\Users\\root\\AppData\\Local\\Temp\\work\\test0\\alloctests-6f6372787480eb2d.exe"
error: test failed, to rerun pass `-p alloctests --lib`
Caused by:
  process didn't exit successfully: `/builds/hlab/rust-ci/rust/build/x86_64-unknown-linux-gnu/stage1-tools-bin/remote-test-client run 0 /builds/hlab/rust-ci/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-win7-windows-msvc/release/deps/alloctests-6f6372787480eb2d.exe -Z unstable-options --format json` (exit status: 57)
note: test exited abnormally; to see the full output pass --no-capture to the harness.

(remote running is used, here under x86_64 Windows 7 SP1, but it also applies to x86)

Manually running the alloctests-*.exe program with std-*.dll alongside it gives the following dialog box:

which can confirmed using depends.exe and observing the function's absence from WS2_32.dll. It could therefore make programs compiled with Rust 1.92.0 systematically fail as well, but I haven't been able to test that just yet.

The only place where this function is used if for std::net::hostname's Windows support, that is still unstable and tracked with #135142. This should explain why it started to fail only now as the feature's initial implementation is recent and only landed in stable under 1.92. As documented, GetHostNameW is indeed only available starting from Windows 8.

Removing this feature's support for Windows 7 should be easy, but ideally it should be adapted or ported to be compatible with Win7. Another possibility would be to use GetComputerNameExW that is available from prehistory times, but I don't know if its semantics are the same as GetHostNameW: would it work for what we want for the feature?

cc @roblabla @orowith2os @joboet

@rustbot label C-bug O-windows-7 T-libs A-io

[orowith2os]

I shouldn't be getting involved. I only made the PR to add the method, and mainly just for other platforms. Windows isn't my forte.

[Fulgen301]

Another possibility would be to use GetComputerNameExW that is available from prehistory times, but I don't know if its semantics are the same as GetHostNameW: would it work for what we want for the feature?

They're not - among other things:

If the GetHostNameW function is used on a cluster resource on Windows Server 2012 and the CLUSTER_NETWORK_NAME environment variable is defined, then the value in this environment variable overrides the actual hostname and is returned. On a cluster resource, the CLUSTER_NETWORK_NAME environment variable contains the name of the cluster.

The GetHostNameW function queries namespace providers to determine the local host name using the SVCID_HOSTNAME GUID defined in the Svgguid.h header file. If no namespace provider responds, then the GetHostNameW function returns the NetBIOS name of the local computer in Unicode.

However, while GetHostNameW (the Unicode variant) has been added in Windows 8, gethostname (the ANSI variant) is from Vista; we can fallback onto it on the win7 target, if GetHostNameW isn't available. (I don't recommend using it unconditionally, that may break if a namespace provider returns a Unicode name.)

[joboet]

However, while GetHostNameW (the Unicode variant) has been added in Windows 8, gethostname (the ANSI variant) is from Vista; we can fallback onto it on the win7 target, if GetHostNameW isn't available. (I don't recommend using it unconditionally, that may break if a namespace provider returns a Unicode name.)

That sounds like the best solution.

@PaulDance for your information, the target tier policy for tier 3 targets like Windows 7 states:

Do not send automated messages or notifications (via any medium, including via @) to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.

so getting a reaction like that from oroswith2os is sort of expected... in the future, may I suggest cross-referencing issues like this in the relevant PR instead? That still results in a notification, but doesn't subscribe people to an entirely new thread.

[PaulDance]

I shouldn't be getting involved. I only made the PR to add the method, and mainly just for other platforms. Windows isn't my forte.

👌

They're not - among other things:

I see, thanks. However, what are the semantics we really want here? From my point of view, the sensitivity to the CLUSTER_NETWORK_NAME environment variable seems like a weird idea, but maybe that is desirable in practice for compatibility with Windows-oriented environments; also, the querying of namespace providers feels like it could be more involved than needed for basic if not most use cases, but I just don't really know what it actually implies.

However, while GetHostNameW (the Unicode variant) has been added in Windows 8, gethostname (the ANSI variant) is from Vista; we can fallback onto it on the win7 target, if GetHostNameW isn't available. (I don't recommend using it unconditionally, that may break if a namespace provider returns a Unicode name.)

I see what you mean, it could work well, yes. However, discarding the possibility of properly handling non-ANSI hostnames seems like it would be a big limitation while GetComputerNameExW is supposedly always available?

for your information, the target tier policy for tier 3 targets like Windows 7 states:

Alright, I didn't know that, sorry.

[Fulgen301]

I see, thanks. However, what are the semantics we really want here? From my point of view, the sensitivity to the CLUSTER_NETWORK_NAME environment variable seems like a weird idea, but maybe that is desirable in practice for compatibility with Windows-oriented environments; also, the querying of namespace providers feels like it could be more involved than needed for basic if not most use cases, but I just don't really know what it actually implies.

GetHostNameW also calls namespace providers, which are part of Winsock's extensible plugin infrastructure. Think userspace network protocols. Those are part of the network hostname as defined by Winsock, and we can't just ignore them. (This also might include the TCP/IP, which would return the DNS name here.)

The point of hostname is to return the hostname as defined by the OS's networking infrastructure, not some other name. Diverging here, even only for a tier 3 OS, would diverge from expected application behavior.

However, discarding the possibility of properly handling non-ANSI hostnames seems like it would be a big limitation while GetComputerNameExW is supposedly always available?

There is no such thing as a Unicode NetBIOS name - NetBIOS names consist of max. 15 bytes in the OEM code page, with a restricted character list.

[Fulgen301]

NetBIOS names consist of max. 15 bytes in the OEM code page

(The exception to this rule is if you manually edit the registry value, as GetComputerNameExW currently does not perform any validation on reading, but only on writing, and will give you back the value in all its glory, but at that point you're violating all the preconditions of both the operating system and the NetBIOS protocol (the host name will be truncated), and this is not a behavior we should care about.)

[PaulDance]

OK, let's go with gethostname then. Thanks for the details.

we can fallback onto it on the win7 target, if GetHostNameW isn't available

Just out of curiosity, how would this dynamic detection go about exactly? Externally, I know of windows_dll that enables this, but it is not used here and I don't think I have yet seen a place in std where such a thing is performed.

---

In the meantime, I'll post a first PR fixing the immediate issue at hand by adding Win7 to the feature's unsupported platforms, and then potentially a second one adding it back to the supported ones with the mentioned solution.

[Fulgen301]

Look for compat_fn_with_fallback! in std/src/sys/pal/windows/c.rs

In the meantime, I'll post a first PR fixing the immediate issue at hand by adding Win7 to the feature's unsupported platforms, and then potentially a second one adding it back to the supported ones with the mentioned solution.

I can PR in a fix in the next couple hours if no one else is working on it, too.

[PaulDance]

I just opened a PR with the mentioned quick fix.

I can PR in a fix in the next couple hours if no one else is working on it, too.

If it is about the full fix, i.e. the use of gethostname, then that would be nice, yes, probably after the above. In any case, I should be able to handle that part, just not in the coming days as I won't (easily) have access to an environment with which I can test things under Win7.

Look for compat_fn_with_fallback! in std/src/sys/pal/windows/c.rs

Ah yes, indeed, thanks. Just to be sure though, for the full fix, it should rather use compat_fn_optional as the two functions don't have the exact same API (the pointer types differ, so could interfere with alignment or byte ordering I guess, and also the maximum buffer length in bytes changes), right?