WineHQ

Clean Room Guidelines: Difference between revisions

(Initial import; some markup fixes)
 
(suppress TOC)
Line 1: Line 1:
__NOTOC__
Wine developers often run into undocumented behavior or interfaces in Windows. When this happens, they use [http://en.wikipedia.org/wiki/Clean_room_design clean-room design] techniques to work around the problem without infringing on any Microsoft copyrights.
Wine developers often run into undocumented behavior or interfaces in Windows. When this happens, they use [http://en.wikipedia.org/wiki/Clean_room_design clean-room design] techniques to work around the problem without infringing on any Microsoft copyrights.



Revision as of 02:15, 14 February 2016

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. (e.g. don't look at the C runtime library source code that ships with their C compiler.)

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 14 February 2016, at 02:15.