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

Hi Francois (et al)

Up until the license change, we had submitted back to WineHQ everything
we had done in every areas of DirectX, with the one exception of Direct3D.
At the time of the license change, we had a few weeks worth of patches
pending that we had been planning on getting to after our release.

You asked how the DirectDraw/Direct3D developers should react to our
work - but you miss a key point, which is that there *were* no developers
working on Wine's support for Direct3D for more than 6 months prior to
our first announcements.  And most of the really significant development
in Wine's Direct3D support happened in early 1999, with earlier versions
of the Direct3D APIs which WineX still doesn't support.

Thus, for developers who want to do more 2D DirectDraw development in
Wine, our contributions are already there to draw upon.

As for developers who want to work on Direct3D, there is plenty of work
required on pre-Direct3D 6 APIs; work which could easily be based on the
work that Lionel did in '99, and which is quite orthogonal to the work that
we have done on later APIs.  Furthermore, if someone wants to do that
work in their spare time, we will be very happy to pay for access to it
in our tree.

So not only is there now more code than there was before, there is
a monetary incentive for anyone who wants to work on that code.

As far as our contributions to typelib and DCOM work go, we have
already made public a substantial amount of our work there, including
contributions to the typelib reader, variants, safearrays, rpc, and ole
automation. If you want to see exactly what we contributed, you can
find it here:

TransGaming's Typelib / DCOM contributions:
     http://206.47.27.235/winestats/dcom_tg.gz

These contributions have, I am quite certain, been helpful to the other
companies who have been working on commercial support for running Microsoft
Office on Wine.  In a simple lines-of-code analysis, we actually contributed
slightly more than Huw did on this front.

We would very much like to make additional contributions of our DCOM work
to Wine - our core business focus is on games related technologies, and
we would rather not be working on other things.  The problem was simply
this: the work on DCOM took significantly more effort than we originally
anticipated, and we simply could not afford to release it without something
in exchange.

We are now offering not only that DCOM code, but much more, in exchange
for just the DLL seperation patches.

Without better DLL seperation support in the ReWind and WineX trees, we
simply have no ability to make use of LGPLed Wine DLLs, and thus no way to
participate in any development of any of the LGPLed code.

It has been suggested by some that we could make use of the LGPLed tree
if we somehow turned our copy protection code into an optionally loaded
library.  Unfortunately, and for a variety of reasons, we do not believe
that would be possible; for example, some of the changes we make are at the
winebuild level.  It may be that over time we can overcome these obstacles,
but at present we see the partial DLL-sharing model as the only feasible
way for us to participate in any cooperation with the LGPLed tree.

Of the changes that we've asked for, the vast majority are owned by
by Alexandre alone, so there would be no legal complexity to accepting
the offer.  As such, I am continuing this discussion in private email
with him.

Take care,
    -Gav

-- 
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com/
[email protected]