Re: Problem with InstallShield (Was Re: [Bug 629] Changed - Problemwith InstallShield: ole:CoTreatAsClass(stub), ole:CoGetClassObject)

On Sat, 11 May 2002, Francois Gouget wrote:

> On Sat, 11 May 2002, Gavriel State wrote:
> [...]
> > Well, I just spent a little time trying to collect some more detailed data.
> > I took all of our patches to dlls/ddraw (excluding headers) submitted to
> > wine-patches from June 2000 to September 2001, and put them here:
> >     http://206.47.27.235/winestats/tg-ddraw.gz
> >
> > And I took all of Marcus' and Lionel's dlls/ddraw patches from roughly the
> > same time period (with one outlying patch in Feb 2002) and put them here:
> >     http://206.47.27.235/winestats/other-ddraw.gz
> [...]
>
> Well, I'm not saying that you did not contribute.

Hmmm, I guess you could argue that I did in a previous email. I
apologize for the confusion, especially if that is what you had in mind.


Now let me... hmmm, maybe it would be best called 'rant a little' :-)
(insert usual disclaimer about ideas being my own and no-one else's)


You do release at least some DirectDraw code. This is what your
statistics show. I don't know if you release all of it, or just parts of
it, and not being a specialist of DirectX I don't know how significant
these contributions are. But I think you play fair as far as DirectDraw
is considered, and even if you keep part of it that's fine by me.



The first problem is with Direct3D. You announced your Direct3D work and
said you would release it as soon as you had reached a given number of
subscriptions:

(http://www.winehq.com/hypermail/wine-devel/2000/12/0358.html)
> Initially, the Direct3D code will be released with limited
> redistribution rights under the Aladdin Free Public License - it will
> not be available under the Wine license.
[...]
> Once a set number of users have subscribed to the service we will
> release the code under the Wine license.  After the initial code is
> released under the Wine license, so will all subsequent patches,
> assuming we retain a set minimum number of subscriptions.

Now what are the DirectDraw/Direct3D developpers supposed to do after
such an announce?
They are not out to get you. So I think that they would submit their
current work and then wait a little,
  by respect for you,
  so as not to cut the grass from under your feet,
  and so as to not duplicate your work.

And I guess that if you had released the code after a few weeks, or even
maybe as much as a few months later, all would have been ok. But
apparently you have not reached your subscription levels because more
than a year later you have still not released the Direct 3D code.

This is in accordance with what you said from the start. Probably even
you did not expect that it would take so long to reach the subscription
levels you wanted. however, please, look at it from the point of vue of
the Wine project now.

Should Wine developpers wait for you to release the Direct3D code to
Wine? Should they find something else to work on? what should they work
on? I mean, someone who loves working on multimedia code is not going to
be thrilled to work on dll separation. Especially if it's for a couple
more years?

Which course of action would *you* recommend? Wait for your code to be
released? Or work on implementing Direct3D on our own?



Then came Installshield 6 / COM / DCOM.

When Ove posted:

(http://www.winehq.com/hypermail/wine-devel/2001/08/0035.html)
> who will volunteer to reverse engineer these SLTG typelibs and make
> Wine able to read them, so I can concentrate on the actual COM
> marshaling stuff (which is pretty hard enough as it is), so we can
> finally get those @#&% InstallShields up?

And Huw started work on implementing SLTG support soon after, I thought,
this was great: CodeWeavers and Transgaming working together for the
benefit of Wine and all involved. This was in the true spirit of
open-source collaboration. But apparently, the 'we' in 'so we can
finally get those @#&% InstallShields up' meant 'Transgaming'. Or rather
it turned that way as I seriously doubt this was what Ove originaly
meant:

(http://www.winehq.com/hypermail/wine-devel/2001/12/0084.html)
> From : Gavriel State ([email protected])
> There are several factors to that equation, and I'm afraid we don't
> have a firm ETA yet.

History was repeating: announce of COM support for Installshield 6,
availability of code under a non-free license, and uncertainty as to the
final release date, maybe years away.

Except that this time this code was quickly reimplemented. I believe
that the lesson is not that when code is deemed useful Transgaming's
actions prevent things from being reimplemented in Wine (as you once
said. plus they don't prevent anyway, they just discourage), but more
that in the year between the two events, Transgaming's karma took a hit.


Now you propose to trade patches. Maybe Huw should have traded the STLG
code for the Installshield DCOM code.

But anyway there's the remainder of the DCOM code, as I said before I
believe that trading is not viable.  Someone said that the nice thing
about the GPL was that it allowed many competing companies to work
together without having to fill a room with lawyers for weeks before
anything could get done.

As I see it, patch trading will be very much the same. Getting all
contributors to agree to trade or even to agree on what should be traded
will take more time (if it gets anywhere at all) than to reimplement the
whatever is being traded. You are welcome to try anyway.

So from my perspective the Wine project again has to decide whether to
wait for you to release that code, or to work on reimplementing it.


For both Direct3D and DCOM I believe that we (the Wine project) should
start working on them right now.


--
Francois Gouget         [email protected]        http://fgouget.free.fr/
          tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY