On Sunday, 6 November 2016 20:55:04 CET you wrote:
On Sun, Nov 6, 2016, 13:32 Ivan Akulinchev ivan.akulinchev@gmail.com
wrote:
If you disassembled user32/comctl32 dlls
Yes, I disassembled comctl32. [...] I believe this action does not violate the Clean Room design.
You are not a lawyer. And even if you were a lawyer, you are not a lawyer
representing the project. What you believe does little to impress a team of lawyers hired by one of the largest companies on Earth.
There is a clear set of guidelines on this topic. https://wiki.winehq.org/Disassembly https://wiki.winehq.org/Clean_Room_Guidelines
You should not miss the common part of my message. I put "believe" at the end just to make the last sentence more polite.
The CLASS_GetVersionedName function was written by me before I started the disassembler at all and I used the similar functions from comctl32/tests/ v6util.h and comctl32/tests/button.c as a basis. I believe this files are "clean" as far as they are already in the Wine source tree (if they aren't, they should be urgently removed out of there, and I should be recognized as a victim).
The next question was where should this function be: user32, comctl32, both of them or somewhere else. Looking at the Wine source code I suggested, that only first two libraries make sense for me, because user32 is the endpoint for all class-related stuff and don't pass the class name to the underling libraries (except the Wine server). Therefore it was clearly, that I should place a copy of this function in user32 (in our case), as far as MSDN says [1] the only thing I need to do to enable the Visual Styles support in my application is to use a manifest file. In other words, this means, that the class names conversation stuff is out of my application (i.e. a part of user32 or its underling libraries, if any). Then (and only then) I tried to locate this function inside the original Microsoft's binary using a disassembler and I was unable to locate it there. Relying on my experience I suggested, that no functions similar to the function I wrote is in the library. Writing the patch I was 100% sure in it, but this doesn't mean, that this function is really out of there (Microsoft could use a very cool anti-disassembling technology to hide this function, but it's very unlikely). Therefore I decided to limit my changes to user32, and the tests I done after (tests were based on comctl32/ tests/v6util.h, comctl32/tests/button.c, comctl32/comctl32.manifest and my own program I wrote based on the Win32 Hello World application from MSDN [2]) confirmed that. Later I had to make some changes in comctl32, because it didn't want to work with my patch. Changing comctl32 I couldn't use the information I learned analyzing the original implementation, because I was unable to find a Microsoft's manual "How to fix Wine after Ivan's patches" there (really, it's stupid to make such statements).
If you read this line and skipped the paragraph above, it's OK. Just say me the laws of what country does the Wine's lawyer use, and I'll find you an authoritative research confirming, that the things I wrote above don't violate the laws of that country (well, the legal system is not mathematics, but I'll likely find a precedent, if this country has such term).
Another question is, what if I'll resend the patch, doing the stuff intentionally "not like in Windows" (it is theoretically possible, but may break some third-party libraries). Or does "doing intentionally not like in X" violate the law as well, if I know, how does X works?
(links to the long paragraph above, skip it, if you didn't read it) [1] https://msdn.microsoft.com/en-us/library/windows/desktop/bb773175.aspx [2] https://msdn.microsoft.com/en-us/library/h9x39eaw.aspx