Is Wine a platform for Codeweaver to make money?! Please help me understand.

[Jeremy White]

Hi Philip,

Philip A. Marshall wrote:
> While we're on the subject, I've got a question about the situation.  I
> know I can go to Codeweavers and download the source for crossover wine.
> But, if someone is trying to review codeweavers patches to "fix them up"
> for wine, that isn't very convenient (I can't imagine a diff of the
> entire source, or even one file, being useful).  I know that a lot of
> codeweavers patches get submitted to wine, but do ALL of them?  Is there
> a way to access the codeweavers wine development tree?  I ask because
> I've seen people post here "There's a hack in crossover that makes that
> work, if you want you can clean it up for wine."  I'm just curious as to
> how easy it would actually be to do that.

Our policy is that all of our work on Wine is submitted to wine-patches *first*.
(There are rare exceptions, but they happen more because of old branches
that are out of sync, or rush jobs, but the basic principle follows
for 99% of our work).

The only time we apply a hack is when there is a practical solution
that is offensive to the @#$@#$ Wine maintainer.

So, for example, the Shockwave player is (was?) a rather, um,
interesting piece of code that basically does a forced spin loop,
bringing a system to its knees when you run it.

We have a lovely piece of 'proprietary advantage' that essentially
detects a message id we know Shockwave likes to send, makes sure that
the current program is shockwave, and then forcibly does a context switch
to make the player behave better.

We also have some logic around thread priority that is not
in mainline WineHQ.  However, that was discussed heavily here,
and you would be far better to look for that discussion here
(look for emails by me from about 2 years ago) and use the patches
that I included at that time, as that way you'll get the
correct context.

Further, there have been a set of alternate patches proposed
that other people are preferring (they require setuid root
bit and use the ability to set priorities that gives) that
might be better.

So that gives you an idea of the sorts of differences that exist.
(Those are just examples I'm familiar with; there are many more).

Frankly, your best bet for leveraging our work is to use Wine from
WineHQ first.  If you run into a problem, it's useful then to compare
it with CrossOver, to see if the behavior is different (90% of the time,
we have the identical bug).  If you do see that CrossOver is better,
then the next steps that would be useful would be to look into our
DLL overrides and try to configure winehq to follow; I'd bet another 50%
of the time that will explain the difference.  Next, download our
Wine source tarball and see if our Wine works when public Wine doesn't.
Then, and only then, would it be worth digging into our source to
see if we have a special hack.  And your best bet would be just to
grep for the application you're trying to run; we usually put
a comment in our code like "Special hack for Shockwave."

As a final counter example, I just this morning figured out that
CrossOver has some lovely code for handling email URLs and such
that is, I think, inferior to the code in WineHQ.
(It's hard to say; WineHQ is relying on xdg-utils, which is a
Good Thing [TM], while CrossOver does it all kinds of bad ucky
old ways, which have the benefit of being more backwards compatible).
But if you're on a modern Linux, WineHQ would be
much better for that purpose than CrossOver, so digging into
the CrossOver patches would be bad.

Hope that helps.

Cheers,

Jeremy