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.
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
On Tue, 2007-04-10 at 13:13 -0500, Jeremy White wrote:
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).
I assumed this is what happened since it makes it easier to keep trees in sync (hence a mutually beneficial solution in the long term), but thanks for the confirmation.
The only time we apply a hack is when there is a practical solution that is offensive to the @#$@#$ Wine maintainer.
Hah, I'm aware of the differing standards between the two projects, hence the curiosity at the process by which differences were managed. Incidentally, I'm not going to weigh in on which set of standards I think are "right", because as far as I'm concerned they're both "right" for the project they're applied to. It's a bit like a "stable" and an "experimental" branch. It will be interesting to see what happens after 1.0: whether "hacks" are more likely to be accepted into the winehq development branch but not merged into trunk releases, or whether they're still rejected for the same reasons they are now.
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."
Thank you, this is exactly what I needed to know. That's certainly a sane way to go about things.
-Philip
-
Jeremy White -
Philip A. Marshall