The rules of wine are about detectability.
It very hard to tell the difference between clean room and someone who has disassembled the program and rewritten the code themselves breaking clean room.
Black box difference is detectable. Simple detectable. The trial and error process of it is completely different.
Legal Issues
-
James Mckenzie
Legal Issues
oiaohm wrote:
Say there is a function (I'm working on this one, so bear with me) that formats text and then puts text into a 'box' that is sized to match a page. This function is described in MSDN (which make it public knowledge) and then we use the tests to insure that MSDN is correct (it has been known to be wildly incorrect). We feed in certain values to the black box and see what comes out. We test all values and even include 'corner tests' which are where functions are supposed to change values but sometimes do not. Clean room means that we delve into the actual code and find out what it does and then attempt to do a better job than the original.
The bottom line here is as I stated before: Wine does not and cannot contain code that is in Windows. We include some programs that provide the same functionality as those included with, but not owned by, Windows. For instance, the Notepad program included with Wine is a public domain program, that has been improved by the Wine project.
One item I do have to stress is that you must read the End User License Agreement (EULA) that comes with any program to insure that you are compliant with its restrictions. The Wine project cannot be held responsible if you are not doing this and are found out of compliance. The Windows XP license does NOT restrict use of the software contained within to only Windows operating systems, although it would be a good idea to have a valid Windows license when doing so. Windows 7's EULA does restrict.
Please also keep in mind that consulting a legal authority in your jurisdiction is also HIGHLY advised before using or installing a program in the Wine environment. Laws and rules do differ from country to country. My opinions are based upon case law here in the United States where companies and software licensees are severely restricted as to what and where they can use software products unless there is an agreement that states differently. The E.U. and other countries have found such licenses unenforceable or invalid.
Please keep in mind that the 2000 copywright agreement was agreed to by many countries and the E.U. which severely restricts code copying as well.
James McKenzie
Correct. That is why we have compliance testing and what we attempt to build functions to.Basically you just claimed wine contains something it does not army_ant7 internals of wined3d no where close to those of Direct3D.
http://en.wikipedia.org/wiki/Black_box_testing Black box testing is technically not reversing.
Say there is a function (I'm working on this one, so bear with me) that formats text and then puts text into a 'box' that is sized to match a page. This function is described in MSDN (which make it public knowledge) and then we use the tests to insure that MSDN is correct (it has been known to be wildly incorrect). We feed in certain values to the black box and see what comes out. We test all values and even include 'corner tests' which are where functions are supposed to change values but sometimes do not. Clean room means that we delve into the actual code and find out what it does and then attempt to do a better job than the original.
It is also against the law in some cases. I know that this is so in the United States and is covered under copywright and patent laws. You cannot replicate, in detail, the functions provided by a certain piece of code.Notice a critical difference Clean Room does not provide patent protection.
Yes. You can duplicate how a Word document is put together. You cannot duplicate the code of the program itself.Black box testing on the other hand. If internal implementations happen to match its independent development. Allowed for under
patent law. Basically once you look inside the black box you are no longer fully independent.
Also clean room can lead to the closure of your project....Clean Room can also be highly costly using lawyers and the like. It is simpler to Black Box than clean room.
This is a good example of what Wine does with complex video calls. It is also why games and the such will never work as well as they do in Windows, if they are built for Windows. You have to convert the DirectX call into an OpenGL call and then convert the results back. This will slow down the screen display. However, if you use a well made OpenGL driver, this can be minimized or even be faster than the DirectX call.Black boxing is simple to prove. Bugs unique to wine have proven it many times over. Followed by testcases to testing function.
Followed by that the internal code is not even close to MS design. MS direct X never redirects to opengl it goes down threw a
completely different hardware path.
Actually, there is undocumented code all over the place in Wine. If we documented each and every call and code piece, Wine would become very large. However, when there is a question where code came from, we can go into git and find out who added what line (with some restrictions) and when.Then there is what called magic code that has a bad habit appearing in clean room and black box works. The magic code style is
unique to each type. Not documented with why it is really doing something is magic code.
True. We should document in stubs why the value returned is needed. As we build out stubs then the comments can be removed.Wine does have some magic code but is normal magic code for blackboxing. Ie stubs that return a value got from black boxing with
no clue why the function is returning that value inputs to function just junked. Note the black box stubs have a logical reason a
test case acquired the result to return. But why the returned value no one is sure.
The above is not necessarily true. Some functions, like the one that I'm working on, will not be accepted if it contains errors. However, if your code 'duplicates' the functioning of other code, then you are not black-boxing or you just happened to hit on the exact same code. The first means that your creditability is gone, the second means someone has to 'fix' your code so that it functions in a different manner. Something like moving the case selections in a switch statement or removing code that is not needed.Clean room/disassemble magic code is different. Inside functions there is magic code performing operations with no logical reason
or data supporting it. This code would normally appear and function correctly without any development process. Ie not natural.
Code normally never just works perfectly normally need to be edited and corrected. It has finger prints. Lack of mistakes
requiring reversions and corrections is a clear warning sign to Clean room or disassemble being used.
If you work on code for a couple of years, you should get it right.Yes history of wine a few developers have been caught being stupid enough to try to sneak disassemble or clean room stuff in. The
lead maintainer does look for the signs. If a developer does get caught there code will be removed from wine. Most cases they
get caught before they have had any of there code merged into the project. Lack of errors is a major giveaway. Its not human to
get it perfectly right first time a lot.
This is very true. It is very hard to 'get the same code' exactly if you are not reverse-engineering. The legal reason for this is that is can end a project, suddenly. So, the Wine project, from the start, has not allowed reverse engineered code. Black boxed code is allowed if you can prove that the results are what are obtained by running test scenarios through a 'black box' or some Windows code. If you cannot, then your code is disallowed. That is why the project requires, for the most part, conformance tests and the more stringent the better. This allow code developers and testers to compare results, not line-for-line code.army_ant7 basically if you had a greater understanding of detection of reversing you would have known it has a signature.
The bottom line here is as I stated before: Wine does not and cannot contain code that is in Windows. We include some programs that provide the same functionality as those included with, but not owned by, Windows. For instance, the Notepad program included with Wine is a public domain program, that has been improved by the Wine project.
One item I do have to stress is that you must read the End User License Agreement (EULA) that comes with any program to insure that you are compliant with its restrictions. The Wine project cannot be held responsible if you are not doing this and are found out of compliance. The Windows XP license does NOT restrict use of the software contained within to only Windows operating systems, although it would be a good idea to have a valid Windows license when doing so. Windows 7's EULA does restrict.
Please also keep in mind that consulting a legal authority in your jurisdiction is also HIGHLY advised before using or installing a program in the Wine environment. Laws and rules do differ from country to country. My opinions are based upon case law here in the United States where companies and software licensees are severely restricted as to what and where they can use software products unless there is an agreement that states differently. The E.U. and other countries have found such licenses unenforceable or invalid.
Please keep in mind that the 2000 copywright agreement was agreed to by many countries and the E.U. which severely restricts code copying as well.
James McKenzie
The basic rules are true. Look back at your patches in the processes of development you have put up ideas how to solve problems and so on. Even at times tried different paths.The above is not necessarily true. Some functions, like the one that I'm working on, will not be accepted if it contains errors. However, if your code 'duplicates' the functioning of other code, then you are not black-boxing or you just happened to hit on the exact same code. The first means that your creditability is gone, the second means someone has to 'fix' your code so that it functions in a different manner. Something like moving the case selections in a switch statement or removing code that is not needed.Clean room/disassemble magic code is different. Inside functions there is magic code performing operations with no logical reason
or data supporting it. This code would normally appear and function correctly without any development process. Ie not natural.
Code normally never just works perfectly normally need to be edited and corrected. It has finger prints. Lack of mistakes
requiring reversions and corrections is a clear warning sign to Clean room or disassemble being used.
Exactly why would you be bothering trying different paths if you know what is inside.
Reversed/clean room source code normally lacks the normal processes of code creation. Would it not be normal for you to put forward patches that get rejected due to over looking something along the way of getting to accepted.
Basically there is a natural process to code development. Coder will miss stuff will have to go back and correct stuff. The give away is the lack of that process being required for functionality.
There is more than one way of documenting you are forgetting about the commit comments. This is still documentation about the code to be correct for detecting reversing the commit data is more useful. Did this function come to life fully functional or did it need alterations to make it work right. You can see alterations to make the code work right in a progressive way some times the alterations will be helpful sometimes they will cause other bugs this is natural. Once you have a set of progressive alterations it not magic code. Progressive alterations says that it happen in the natural way code does. Yes common mistake when I say documentation people think in source code docs not history and comments on the code that are stored in a independent archive. This also tracks who submitted what this is also handy to work out if anyone is breaking the rules.
I should have been more correct with clean room it magic code that is functionally correct without a development process to get there. Probability of doing that once without clean room or reversing is insanely rare. Doing it twice is almost to the point of impossible.
Black box it also insanely rare to funny test a function first time and find all bugs and quirks of a function. Another thing that gives people who have reversed or clean roomed away if they try building black box test cases after the fact breach of natural process.
Also helps that lot of windows functions have very odd bugs that have to be detected. Lot of code for wine at first does not contain this odd bugs. Ie reversed code would.
There are signatures all threw wine code history pointing to the fact it black box code. Non black box would not have the same history.
...
@ryan woodsmall: I didn't mean to ask that kind of question. It's just because of this: http://wiki.winehq.org/Direct3D_Debuggi ... irect3d%29. It uses the name Direct3D and contains talk about debugging which caused me to ask that question, but I am certainly not trolling, mind you. I look at Wine with respect especially for its noble efforts, but I do apologize for making you think I was trolling, it must have been the way I asked the question. Also, no offense, but I don't think the link you sent about clean rooming is the one we are talking about. I may be wrong on this one still though. Thanks on the info though!
@oiaohm: I think I got what you were saying, but your grammar, well, no offense too, was a little off, so I had a little, hard time comprehending. I'll try researching on magic code though. Your statements do sound agreeable and logical though. May I ask another question though? Here, http://wiki.winehq.org/WineD3DOnWindows ... wined3d%29, it says some thing about using Direct3D DLL's. DLL's are libraries right? I'm just wondering if it is referring to WineD3D libraries. WineD3D is not derived in any way from Direct3D, but just black boxed right? Is it? One more thing, OpenGL is implemented in Wine right? Is OpenGL also made from scratch and black boxed?
I hope you can answer my questions. Thanks! You increased my, and maybe other's, understanding of Wine.
@James Mckenzie: Hi. I was about to ask this, "How can you know if someone studied the internals of another program before making his own program from scratch and claiming to just have black boxed it; or what if by chance a person truly black boxes a program but is accused of clean rooming because the codes of his program and another are so similar that others may say he just rearranged the code?" from oiaohm, but you seem to have answered it for him. Thanks for that! You said though, Your grammar was great! I clearly understood you. I have same compliments for you like those I gave oiaohm. I'd appreciate it too if you try answering the questions I asked him. I values both of your opinions.
Thank you all!
@oiaohm: I think I got what you were saying, but your grammar, well, no offense too, was a little off, so I had a little, hard time comprehending. I'll try researching on magic code though. Your statements do sound agreeable and logical though. May I ask another question though? Here, http://wiki.winehq.org/WineD3DOnWindows ... wined3d%29, it says some thing about using Direct3D DLL's. DLL's are libraries right? I'm just wondering if it is referring to WineD3D libraries. WineD3D is not derived in any way from Direct3D, but just black boxed right? Is it? One more thing, OpenGL is implemented in Wine right? Is OpenGL also made from scratch and black boxed?
I hope you can answer my questions. Thanks! You increased my, and maybe other's, understanding of Wine.@James Mckenzie: Hi. I was about to ask this, "How can you know if someone studied the internals of another program before making his own program from scratch and claiming to just have black boxed it; or what if by chance a person truly black boxes a program but is accused of clean rooming because the codes of his program and another are so similar that others may say he just rearranged the code?" from oiaohm, but you seem to have answered it for him. Thanks for that! You said though,
andBlack boxed code is allowed if you can prove that the results are what are obtained by running test scenarios through a 'black box' or some Windows code.
I found the last part, "...or some Windows code." of the former, and the latter to be contradictory. I may have just understood it wrong though. Please clarify though if you may.Wine does not and cannot contain code that is in Windows.
Your grammar was great! I clearly understood you. I have same compliments for you like those I gave oiaohm. I'd appreciate it too if you try answering the questions I asked him. I values both of your opinions.Thank you all!
My english sux yes that is nothing new to me.
magic code/magic values is a old term normally used in legal cases about breaches. Not exactly a general term you will find any where. People performing magic can make items seam to appear from no where by slide of hand. Magic code and magic values are the same kind of thing. If you understand where they came from they are no longer magic.
http://en.wikipedia.org/wiki/Magic_numb ... ramming%29 Use of magic for strange things in programming is a really old term.
Basically magic code/magic values are unexplainable appearances of stuff. Where unexplained appears is unique to the development method.
Program written completely new from scratch normally will contain no magic items everything will be appearing out of the natural cycle.
Program written new but using a standard file format and other documents can have some data from the documents appearing in the program like magic. One of the most common magic values is the magic number used to identify file types.
Program written by black box will have magic values appearing as stubs first then the stubs latter on developing threw to more and more functional functions.
Program written by clean room will have a lot more magic items appearing without a development cycle to get there. Basically the stuff appearing like by magic is evidence. Basically it the stuff appearing by magic that tells you what the developers are doing.
Remember black boxing does include running MS Dlls in contained environments monitoring data sent to them and there matching requests. This is still test casing. At no time is the black box of the dll disassembled. Black boxing also uses the substitution test. You think you have worked out the black box so you substitute it with you own implementation and see if it still works right. That is what WineD3D debugging recommends.
Wine's Direct3D implementation << Need to be read a whole. That is not MS Direct 3D. Wined3d is wine's Direct3D implementation. Problem is for new people working on wine it sometimes required to place documentation where they would expect to find it army_ant7.
If you read the direct3d debugging page you will notice the tittle is Direct3d but then it starts talking about Wined3d.
In WineD3D on windows it lists wine replacement direct dlls that will work on windows and other issues using wine parts. Virtual machine builders of wined3d send wined3d directly to the ICD. They made the ICD so they know what is there.
Opengl is a open standard. Wine mostly does not have a opengl implementation instead its mostly a direct pass through with emulated interfaces of wgl written directly from the standard documentation. wgl interface opengl32.dll has is fully documented. No reversing or black-boxing required. Note Fully documented by MS of all things and correct. This is very much shock horror is one of the few API that MS has documented that they have not had a function with a glitch somewhere.
PS with me its grammar or spelling army_ant7. I can only do one or the other.
magic code/magic values is a old term normally used in legal cases about breaches. Not exactly a general term you will find any where. People performing magic can make items seam to appear from no where by slide of hand. Magic code and magic values are the same kind of thing. If you understand where they came from they are no longer magic.
http://en.wikipedia.org/wiki/Magic_numb ... ramming%29 Use of magic for strange things in programming is a really old term.
Basically magic code/magic values are unexplainable appearances of stuff. Where unexplained appears is unique to the development method.
Program written completely new from scratch normally will contain no magic items everything will be appearing out of the natural cycle.
Program written new but using a standard file format and other documents can have some data from the documents appearing in the program like magic. One of the most common magic values is the magic number used to identify file types.
Program written by black box will have magic values appearing as stubs first then the stubs latter on developing threw to more and more functional functions.
Program written by clean room will have a lot more magic items appearing without a development cycle to get there. Basically the stuff appearing like by magic is evidence. Basically it the stuff appearing by magic that tells you what the developers are doing.
Remember black boxing does include running MS Dlls in contained environments monitoring data sent to them and there matching requests. This is still test casing. At no time is the black box of the dll disassembled. Black boxing also uses the substitution test. You think you have worked out the black box so you substitute it with you own implementation and see if it still works right. That is what WineD3D debugging recommends.
Wine's Direct3D implementation << Need to be read a whole. That is not MS Direct 3D. Wined3d is wine's Direct3D implementation. Problem is for new people working on wine it sometimes required to place documentation where they would expect to find it army_ant7.
If you read the direct3d debugging page you will notice the tittle is Direct3d but then it starts talking about Wined3d.
In WineD3D on windows it lists wine replacement direct dlls that will work on windows and other issues using wine parts. Virtual machine builders of wined3d send wined3d directly to the ICD. They made the ICD so they know what is there.
Opengl is a open standard. Wine mostly does not have a opengl implementation instead its mostly a direct pass through with emulated interfaces of wgl written directly from the standard documentation. wgl interface opengl32.dll has is fully documented. No reversing or black-boxing required. Note Fully documented by MS of all things and correct. This is very much shock horror is one of the few API that MS has documented that they have not had a function with a glitch somewhere.
PS with me its grammar or spelling army_ant7. I can only do one or the other.
-
James Mckenzie
Legal Issues
army_ant7 wrote:
The point is that the Wine project contains no line-for-line Windows code. Yes, we replicate the Windows32 API and are working on expanding/improving the code and adding Win16/WindowsOnWindows64 code, but this project is far from complete and there are portions of the API that are undocumented as well.
James McKenzie
Here is the clarification: You can run a test against a Windows Dynamically Linked Library, say riched20.dll looking for the results for a specific test. In my case, this is EM_FORMATRANGE and the dll comes from WindowsXP. I get back values for specific input values. Since I know only what is MSDN, I input a window handle, the call name, TRUE or FALSE, an invalid input value of zero and a FORMATRANGE structure location, I then look at what is returned for each. Then I post the results and build code to replicate what is returned from the call into Wine code. I did not do the original code but I have refined it and am now looking at one final fix so that the code will return the values returned by the call in Windows. That is what black-boxing is about. Now, if I did this with reverse engineering or clean room code, I would run the .dll through a code reversal process that would give me an approximation of the original c or C++ code. Now, if the original programmer threw in 'junk code' this would be detected and I could option to remove it. However, the original code base would remain and I would be liable for a copyright violation. Using a black-box approach, even by several programmers, is not a liable incident, unless the laws or judicial rulings change.
@James Mckenzie: You said though,andBlack boxed code is allowed if you can prove that the results are what are obtained by running test scenarios through a 'black
box' or some Windows code.I found the last part, "...or some Windows code." of the former, and the latter to be contradictory. I may have just understood itWine does not and cannot contain code that is in Windows.
wrong though. Please clarify though if you may.
you like those I gave oiaohm. I'd appreciate it too if you try answering the questions I asked him. I values both of your opinions.
The point is that the Wine project contains no line-for-line Windows code. Yes, we replicate the Windows32 API and are working on expanding/improving the code and adding Win16/WindowsOnWindows64 code, but this project is far from complete and there are portions of the API that are undocumented as well.
James McKenzie
:-D
Thanks guys for clarifying. In truth, I struggled comprehending, after all I'm only in high-school... Hahaha... But if what you guys say is true then, yup ot does sound that Wine is legally ok. But James, I'm wondering about the thing you said. Do you mean "refine" as in modifying by black boxing? So you only refined the functions then? And about using Windows DLL's, just to clarify are libraries the same as API's in the sense that they contain routine functions that are used by different programs?
Sometimes functions will have to be refined as their first implementation didn't seem to match the original implementation 100%. For example, the original function turns out to return a value of 25 where Wine's implementation returns 0 for any reason whatsoever. These are things that should be fixed to get exact Windows behaviour on the function, but of course it's all still blackboxed.
