[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