Installshield 6 (inter-proc) patches

[Gavriels State]

Alexandre Julliard wrote:
> >   We do have a bit of merge work pending for non-3D components, which
> >   we hope to get to soon.  The delays there have nothing to do with
> >   licensing issues though - they're more about development process and
> >   CVS policy.
> 
> It may be a good idea for you to give some more details about that; it
> would probably help clear up some misunderstandings.

Sure: We have a separate CVS tree that we use for our releases, which 
we're now doing roughly monthly.  We try to ensure that we have a
period of relative stability in tree before releasing.  Merging from
WineHQ into our tree is very destabilizing for us, especially given
some of the rearchitecture work that has taken place recently.  For
example, moving window-list-walking into the server gave us a 20% 
or higher performance loss in many games due to the increase in 
server-call overhead; one of the fixes in our pending queue deals 
with this problem.

Because of this, we tend to try to minimize the inward merges we 
do (our last was over 2 months ago).  This, in turn, makes outward
merges more difficult for us.

In addition to the above, another problem we face with merging is 
that the D3D code has tendrils in the core DirectDraw code which 
makes seperating the two for licensing purposes challenging.  

On the flip side of things, you are more strict about the code
that goes into WineHQ CVS than we are on our side.  We have a number
of changes on our side that provide useful functionality, but are not
clean enough or proven enough to go into WineHQ.  IE: the patch that 
we recently submitted for [Read/Write]ProcessMemory.  It works for the
problem we were experiencing (a copy-protection related thing: the 
various protection systems tend to use WriteProcessMemory all over the
place), but you raised some concerns about other cases and wanted to 
see some of the trace data which we have not had the time to put 
together.

Some of the other things that we have in our tree that fall into a 
similar catagory are:
 - GDB Remote debugging
 - Gerard Patels' deferred tracing patch
 - Auto-detection & adding of CD-ROM devices
 - The heap management fix discussed in October
 
Note that I'm not saying you're wrong to not include these in WineHQ
CVS.  There are certainly many benefits to keeping the tree under
strict control, as you have, but the difference in policy has a
tangible effect on the ease of our merge process.  

I think that the strictness may also have other effects on the speed
with which the project progresses. Certainly reviewing wine-patches 
and doing the CVS commits and testing must take up a large portion 
of your own time on the project.  

> I understand very well that you don't have time to spend on merging,
> but you don't have to: all you have to do is slap the Wine license on
> your code, and I'm sure someone else will be happy to do the merging
> for you. The fact that you don't do this gives the impression that you
> don't want to make the code available, even if that's not your real
> intention.

Well, as I mentioned above, a certain amount of work on our part is 
required to properly separate 2D code from 3D code.  Once we've had 
a chance to do that, I would be happy to accept help with our next
outward merge.  I spent a bit of time this evening preparing a diff
of our code against our previous inward merge, and doing a rough 
first cut of code that can go to WineHQ (about 10k line of diff).  
If there's a real interest in helping us merge this in, I'd be happy 
to fix it up a bit more and post it to the mailing list under the 
Wine license.

 -Gav 

-- 
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
gav at transgaming.com