[PATCH] user32: Add support for class versions

Ivan Akulinchev ivan.akulinchev at gmail.com
Sun Nov 6 17:15:24 CST 2016


On Sunday, 6 November 2016 20:55:04 CET you wrote:
> On Sun, Nov 6, 2016, 13:32 Ivan Akulinchev <ivan.akulinchev at 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



More information about the wine-devel mailing list