Installshield 6 (inter-proc) patches

[Ove Kaaven]

On Sun, 9 Dec 2001, J.Brown (Ender/Amigo) wrote:

> Any idea when Oves interprocess patches will be put into the main Wine CVS
> tree?
> 
> The code currently in WineX isn't really that ugly at all, and it is a
> very important part of Wine to have working IS6 support.

Well, not all of it is ugly, but some crucial bits are. Here is the
biggest reason I never considered that patch eligible for inclusion into
official Wine without a cleanup:

dlls/ole32/ole32.spec:
@ cdecl COM_ConnectProxy(ptr ptr) COM_ConnectProxy

An internal procedure exported from ole32, to be used by oleaut32... YUCK

Another big issue is CoMarshalInterThreadInterfaceInStream, which simply
can't do the right thing with the way I structured things, and I believe
that is why repainting doesn't work while installing. The correct
functionality requires proxying between COM apartments, without any class
activation being involved, which calls for a completely different
communication structure than what those hacks use.

I'm still working on the restructure that is supposed to fix these issues.
So it is my preference that the current InstallShield patches *not* be
applied to WineHQ, but my new upcoming code be used instead. It should be
ready within a couple of weeks.

As to the political issues discussed on this thread, I'm not supposed to
give any kind of official comment, but I suppose I could tell you my
personal view on the situation.

I'd personally love to submit all my code directly to WineHQ under the X11
license, without hesitation, even though it did take me a long time to get
that code working. However, it was Gav who gave me money I could pay my
bills with during the long hours I spent working on it, so I feel obliged
to help him recoup that investment in any way he can. Whatever strategy
he'll use to do so, is up to him. But in my opinion, my code (the
rewritten code, that is, not the old code currently in WineX) is
eventually destined for WineHQ, the only negotiable issues for me are
when, how, and who pays for it.

As for the license of Wine, I was among the ones opposing the LGPL last
time it was discussed, and I have not changed my mind. I feel that Wine is
most widely useful if it keeps the X11 license, and usefulness is more
important in my mind than making it 50% harder for companies to "steal"
the code. If X11 is so bad for large projects such as Wine, why is the
largest project of all, XFree86 (and associated projects like DRI), still
using it, even though its maintainer would have the power to switch to
e.g. the LGPL or even GPL with a snap of the fingers ("sublicensing" it)?

I think Alexandre is not quite correct in his projection that making Wine
code available under a semi-open-source license unconditionally inhibits
work on the free version of Wine. I think that there's a completely
*different* reason that people do not work on the free version, which is
the prevention of duplicate work, in order to preserve precious
development resources. The code in WineX will eventually go back to Wine,
hence there's no reason to duplicate development. If people thought WineX
code would never go back to Wine, I'm sure they would continue working on
the free Wine. I know I would. But when the code *will* go back to Wine,
having people getting paid for doing it fulltime is better than wasting
precious volunteer time on duplicating that kind of work for a much slower
progress... I think Wine will do well by keeping the X11 license, and I'm
not speaking for my employer.

I've periodically tried to merge most of the stuff we do in WineX (other
than Direct3D) back into Wine, both to make the free version as usable as
possible, and make it so that people *can* work on the free version of
e.g. DirectX without fear of duplicating our work (and I think Marcus and
Lionel wanted to add Xv support to the free version of ddraw/x11drv HAL,
they're completely free to do so now without too many conflicts, I reckon
they just haven't had the time yet). However, I only do such merges when I
consider the official Wine to be in a relatively stable state, which it
hasn't been recently due to Alexandre's rewrites of this and that, so I
haven't had the opportunity to merge everything I wanted to merge back
yet...

Well, I think that's pretty much what I wanted to say. But I only speak
for myself; for official TransGaming position statements, look for
postings by Gav...