WineHQ

Clean Room Guidelines

Revision as of 18:47, 23 April 2020 by Zf (talk | contribs) (add some things that have caused problems before...)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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

Quotes

Henri Verbeet

"For what it's worth, the policy I've personally been using has been to simply avoid unnecessary risk."


This page was last edited on 23 April 2020, at 18:47.