wavefnd / wavefnd/Wave

Track remaining Windows std::sys provider work

Open
#385 0 comments 0 reactions 0 assignees View on GitHub
cross-platform enhancement help wanted os support
Dominant language
Rust
Stars
53
Forks
16
Avg merge
4h 22m
Merged PRs (30d)
46

Description

## Summary

PR #422 established the Windows `std::sys` source provider and native CI baseline. The remaining work is no longer “add a Windows provider tree”; it is to replace explicit compatibility stubs with native Windows behavior and verify the resulting public APIs.

This issue now tracks the remaining Windows platform layer at an umbrella level. Implementation should happen in the focused child issues below.

## Completed in #422

- Windows x86_64 provider selection and source-compilation contract
- native filesystem, environment, memory, time, socket, and process foundations
- system-ABI declarations for Windows APIs
- native Windows CI compilation and standard-library examples
- portable HANDLE transport through the descriptor-facing layer

## Remaining focused work

- [ ] #429
- [ ] #430
- [ ] #431
- [ ] #383 for system randomness
- [ ] Define the portable behavior of POSIX-only process and descriptor operations
- [ ] Expand native Windows runtime fixtures as each provider becomes functional

## Completion criteria

- Focused child issues are complete or intentionally documented as unsupported.
- High-level `std` APIs do not silently treat `-ENOSYS` as success.
- Windows CI runs observable native behavior tests, not only source compilation.
- Resource ownership for HANDLE, SOCKET, process, thread, pipe, and console objects is tested.
- The capability matrix in #378 accurately distinguishes implemented, stubbed, and unavailable APIs.

## Non-goal

Windows does not need architecture-specific source directories unless an ABI or native API contract actually differs by architecture.

Contributor guide

Open the contributing guide

Research direction

Start with the focused child issues #429, #430, #431, and #383, using PR #422 for the existing Windows provider baseline and #378 for the capability matrix. Work should be scoped to a child issue; done means the focused work is complete or documented as unsupported, native behavior is tested in Windows CI, and resource ownership is verified.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
operating-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.