WineHQ

Clean Room Guidelines: Difference between revisions

(add some things that have caused problems before...)
(→‎Don't: added ReactOS code to the list of things to not look at)
Line 20: Line 20:
* 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 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 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 us. [https://bugs.winehq.org/show_bug.cgi?id=50464#c6]


=== Quotes ===
=== Quotes ===

Revision as of 00:51, 18 June 2022

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.
  • 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 us. [1]

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 18 June 2022, at 00:51.