ergonomic-windows 0.1.0

Ergonomic, safe Rust wrappers for Windows APIs - handles, processes, registry, file system, UI controls, Direct2D graphics, and more
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150

# Contributing to ergonomic-windows


Thank you for your interest in contributing! This document provides guidelines and information about contributing to the project.

## Code of Conduct


Please be respectful and constructive in all interactions.

## Getting Started


1. Fork the repository
2. Clone your fork: `git clone git@github.com:YOUR_USERNAME/ergonomic-windows.git`
3. Create a branch: `git checkout -b feature/your-feature-name`
4. Make your changes
5. Run tests: `cargo test`
6. Run lints: `cargo clippy --all-targets --all-features`
7. Format code: `cargo fmt`
8. Commit your changes
9. Push to your fork
10. Open a Pull Request

## Development Setup


### Prerequisites


- Windows 10/11
- Rust stable toolchain (MSRV: 1.70.0)
- Git

### Building


```bash
# Debug build

cargo build

# Release build

cargo build --release
```

### Testing


```bash
# Run all tests

cargo test

# Run specific test

cargo test test_name

# Run benchmarks

cargo bench

# Run with memory profiling

cargo run --bin memory-profile --features dhat-heap
```

### Fuzzing (requires nightly)


```bash
cd fuzz
cargo +nightly fuzz run fuzz_strings -- -max_total_time=60
```

## Pull Request Guidelines


### Before Submitting


- [ ] Code compiles without warnings
- [ ] All tests pass
- [ ] `cargo clippy` reports no warnings
- [ ] `cargo fmt` has been run
- [ ] Documentation is updated if needed
- [ ] Commit messages are clear and descriptive

### PR Requirements


1. **One concern per PR**: Keep PRs focused on a single feature or fix
2. **Tests**: Include tests for new functionality
3. **Documentation**: Update docs for API changes
4. **Breaking changes**: Clearly document in PR description

## Code Style


- Follow Rust idioms and conventions
- Use `#[inline]` hints for hot paths
- Document all public APIs with examples
- Add safety comments to all `unsafe` blocks
- Prefer zero-allocation paths where possible

### Safety Guidelines


When working with `unsafe` code:

1. Document all safety requirements in `# Safety` sections
2. Add `// SAFETY:` comments explaining why the unsafe operation is sound
3. Minimize unsafe scope
4. Prefer safe abstractions over raw unsafe code

## Commit Messages


Use clear, descriptive commit messages:

```
feat: add WideString::with_capacity for pre-allocation

- Allows users to pre-allocate buffer capacity
- Reduces allocations in tight loops
- Includes documentation and tests
```

Prefixes:
- `feat:` - New feature
- `fix:` - Bug fix
- `docs:` - Documentation only
- `perf:` - Performance improvement
- `refactor:` - Code refactoring
- `test:` - Adding tests
- `ci:` - CI/CD changes
- `deps:` - Dependency updates

## Reporting Issues

When reporting bugs, please include:

1. Windows version
2. Rust version (`rustc --version`)
3. Crate version
4. Minimal reproduction code
5. Expected vs actual behavior

## Feature Requests

We welcome feature requests! Please:

1. Check existing issues first
2. Describe the use case
3. Propose an API design if possible
4. Explain why existing solutions don't work

## Questions

For questions:

1. Check the documentation
2. Search existing issues
3. Open a question issue if still unclear

## License

By contributing, you agree that your contributions will be licensed under the same dual MIT/Apache-2.0 license as the project.