mirror of
https://gitlab.winehq.org/wine/wine.git
synced 2025-08-28 10:13:55 +02:00
Page:
Clean Room Guidelines
Pages
256 Color Mode
3D Driver Issues
AFD
AMD64
ARM
ARM64
ARM64EC Toolchain
Acknowledgements
Android
Apps That Support Wine
Bottling Standards
Bug Triage
Bugs
Building Biarch Wine On Ubuntu
Building Wine
Buildroot
CentOS RHEL
Clang
Clean Room Guidelines
Cmd Conformance Tests
Code Coverage
Code Hygiene
Code In
Commands
Compatibility
Conformance Tests
Copy Protection
Create Fonts
Create Icons
Cygwin and More
DOSBox
Debian Ubuntu
Debug Channels
Debugging Hints
Designers
Developer FAQ
Developer Hints
Developers
DirectDraw
DirectPlay Games
DirectX D3DX9
Disassembly
Distributed build with icecream
Distrobox development environment
Documentation
Download
Emulation
FAQ
Fedora
Forum Posting Guidelines
Forums
FreeBSD
Gcc
Gecko
Git Wine Tutorial
Guest Unit Tests
Haiku
Hardware
Hurd
IRC
Importance of Wine
Known Issues
Licensing
MIDI
MacOS Building
MacOS FAQ
MacOS
Mageia
Make Test Failures
Man Pages
Multiarch
News
OpenSUSE
Ospp Summer Code
Outreachy
Packaging
Performance
Pop! os
Portable Wine
Preloader Page Zero Problem
Previous Summers of Code
Project Organization
Public Relations
Regression Testing
Reverse Regression Testing
Sound
Source Code
Source Tree Structure
Stable Rules
Static Analysis
Submitting Patches
Summer Of Code
Third Party Applications
Translating
Uniscribe
Usage Statistics
Useful Registry Keys
Vim Tips
Web Design Tasks
Who's Who
Wine Developer's Guide
Wine Features
Wine History
Wine ICU
Wine Installation and Configuration
Wine Mono
Wine Status
Wine TestBot VMs
Wine TestBot
Wine User's Guide
Wine and Valgrind
WineConf
WineGUI
Winelib User's Guide
Winelib
Winetricks
Winezeug
Writers
home
No results
2
Clean Room Guidelines
Alexandre Julliard edited this page 2024-09-17 14:03:05 +02:00
Table of Contents
Wine developers often run into undocumented behavior or interfaces in Windows. When this happens, they use clean-room design techniques to work around the problem without infringing on any Microsoft copyrights.
Do
Here are some techniques believed to be safe for Wine contributors:
- ✅ When trying to understand a Windows API function, write a test program that verifies its behavior, and contribute it to Wine's conformance test suite.
- ✅ It's also ok to look at MSDN (but take it with a grain of salt).
- ✅ But play it safe - if a test program will do, don't look at any Microsoft doc or headers.
- ✅ When in doubt, ask on the wine-devel mailing list!
Don't
Here's a short list of things for Wine contributors to avoid. It is by no means a complete list; all contributors need to be thoughtful about copyrights and avoid violating any law.
- ❌ Don't write a test program that prints out the values of an internal table.
- ❌ Don't disassemble Microsoft code.
- ❌ Don't look at any Microsoft source code, even if it's made "public" under some license, e.g. don't look at the C runtime library source code that ships with their C compiler. Note that as an exception, code that is released under the MIT license (or another LGPL-compatible license) is OK to look at and copy from (with proper attribution).
- ❌ Don't use +relay with native components. In general, try to avoid debugging with native components, as that leaks information about what function calls those components make.
- ❌ Don't examine debug symbols for Microsoft code.
- ❌ Don't look at ReactOS code either (not even header files). A lot of it was reverse-engineered using methods that are not appropriate for Wine, and it's therefore not a usable source of information for us1.
Quotes
Henri Verbeet
"For what it's worth, the policy I've personally been using has been to simply avoid unnecessary risk."