Skip to content

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

Closed
#150905
#150909
Closed
std's tests fail to dynamically link under Windows 7 due to GetHostNameW missing#150896
#150905
#150909
Labels
A-ioArea: `std::io`, `std::fs`, `std::net` and `std::path`C-bugCategory: This is a bug.O-windows-7OS: Windows 7 or Windows Server 2008 R2 or etc.T-libsRelevant to the library team, which will review and decide on the PR/issue.

Description

@PaulDance
PaulDance
opened on Jan 9, 2026

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:

Image

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

Activity

  1. rustbot
    added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    A-ioArea: `std::io`, `std::fs`, `std::net` and `std::path`
    C-bugCategory: This is a bug.
    O-windows-7OS: Windows 7 or Windows Server 2008 R2 or etc.
    T-libsRelevant to the library team, which will review and decide on the PR/issue.
    on Jan 9, 2026

  2. orowith2os commented on Jan 9, 2026

    @orowith2os
    orowith2os
    on Jan 9, 2026

    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.

  3. Fulgen301 commented on Jan 9, 2026

    @Fulgen301
    Fulgen301
    on Jan 9, 2026
    Contributor

    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.)

  4. joboet commented on Jan 9, 2026

    @joboet
    joboet
    on Jan 9, 2026
    Member

    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.

  5. PaulDance commented on Jan 9, 2026

    @PaulDance
    PaulDance
    on Jan 9, 2026
    ContributorAuthor

    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.

  6. Fulgen301 commented on Jan 9, 2026

    @Fulgen301
    Fulgen301
    on Jan 9, 2026
    Contributor

    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.

  7. Fulgen301 commented on Jan 9, 2026

    @Fulgen301
    Fulgen301
    on Jan 9, 2026
    Contributor

    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.)

  8. PaulDance commented on Jan 9, 2026

    @PaulDance
    PaulDance
    on Jan 9, 2026
    ContributorAuthor

    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.

  9. Fulgen301 commented on Jan 9, 2026

    @Fulgen301
    Fulgen301
    on Jan 9, 2026
    Contributor

    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.

  10. PaulDance commented on Jan 10, 2026

    @PaulDance
    PaulDance
    on Jan 10, 2026
    ContributorAuthor

    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?

  11. matthiaskrgr
    added a commit that references this issue on Jan 24, 2026

    Rollup merge of rust-lang#150905 - PaulDance:patches/unsupport-win7-h…

    fd5f48f
  12. rust-bors
    closed this as completedin fd5f48fon Jan 25, 2026
  13. rust-timer
    added a commit that references this issue on Jan 25, 2026

    Unrolled build for #150905

    4e1c187
  14. github-actions
    added 3 commits that reference this issue on Jan 25, 2026

    Rollup merge of #150905 - PaulDance:patches/unsupport-win7-hostname, …

    83e78f6

    Rollup merge of #150905 - PaulDance:patches/unsupport-win7-hostname, …

    94773cd

    Rollup merge of #150905 - PaulDance:patches/unsupport-win7-hostname, …

    71935b4
  15. jieyouxu
    removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Jan 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-ioArea: `std::io`, `std::fs`, `std::net` and `std::path`C-bugCategory: This is a bug.O-windows-7OS: Windows 7 or Windows Server 2008 R2 or etc.T-libsRelevant to the library team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions