Open haraldh opened 5 years ago
Because they were implemented in a rather recent version of Windows 10.
meanwhile I created a crate for it https://crates.io/crates/uds_windows
Is the argument here "only a recent version of win10 supports it, so it doesn't belong in STD" or "only a recent version of windows 10 supports it, so nobody has added support yet?"
Definitely the former because std
supports Windows 7 as a tier 1 platform. Considering you can use a third party crate for unix domain sockets on windows as is, there is very little reason to put them in std
.
I'd love to see this feature make it's way eventually. Cross-linking a conversation on internals for discoverability.
As an FYI: I am working on a pre-RFC for min_target_api_version
which allows for conditional compilation based on the minimum support API version for the target platform. This could address the issue that this would not be supported on older versions of Windows. With this mechanism, Unix sockets would only be available when compiling for a min_target_api_version
that supports Unix sockets. Though this would likely only benefit those who build their own version of the standard library.
Hello from 2022 :wave: Just wanted to provide some updated info here
Windows 10 version 1803, the version introducing UDS, is now over four years old. This and all earlier Windows 10 version has reached end of mainstream service already.
Windows 10 1803 is older than:
this is silly. imo the std's code should have support for both either through different code or with an wrapper api. if the user pics UDS while targeting w7 its on them imo.
Hello from 2023 👋, Any progress on this?
What is blocking this from happening? Is the stance still that Windows 7 does not support this so it won't happen? At what point will Windows 7 no longer be a Tier 1 platform? Even the extended security updates have now ended And why does it even matter? Is it to have consistency between operating systems Even though there are already features, such as ironically Unix Domain Sockets, that only work on certain operating systems.
I know that a third party library allows them to be used. However it becomes an extra hurdle for UDS adoption on windows. As can be seen in the mentions, there are crates that only support Linux because of this issue. For example, I personally wanted to use them for a Deno project but found out that UDS is stuck in unstable due to this issue. Which is a shame in my opinion...
Prefixing this with "not a Rust project member" but now that Windows 7 and 8 have had their end-of-support defined for Rust in https://github.com/rust-lang/compiler-team/issues/651, sometime early 2024 seems like it would be a uncontroversial time to start an implementation of UDS for Windows backends because the stdlib can assume only 10+ will run its code.
If anyone would like to make progress on this issue then a way forward would be to make an API Change Proposal (ACP) that details the proposed API. If accepted, it would then of course need someone to implement it.
https://github.com/libuv/libuv/issues/2537#issuecomment-1618338474
no need to bother with unix domain socket on windows
The Windows implementation of AF_UNIX
does not support abstract sockets. The bug is the lack of documentation on what is supported and that the announcement blog post includes misleading information. Filesystem based UDS works.
Golang implements AF_UNIX on Windows, maybe it can be a reference
The issue is not the implementation (which is simple enough). The problem is the API design. Somebody likely needs to create an API Change Proposal that sketches the design and notes the issues. There's already one, in fact. https://github.com/rust-lang/libs-team/issues/271
Update: The API Change Proposal was just accepted. So now we do just need the implementation.
Seeing https://github.com/Azure/mio-uds-windows .. Is there any reason why UDS are not implemented in the standard library for Windows?