Installshield 6 (inter-proc) patches

[Patrik Stridvall]

> Patrik Stridvall <ps at leissner.se> writes:
> 
> > So you mean that all the people that are current voluntering
> > to work of Wine won't work on Wine if it is almost complete
> > just because somebody else have done the parts they need
> > to run their applications and that they will happily pay for
> > the right to use it.
> 
> No, I'm not saying they won't work on it when it's almost complete.
> I'm saying that there may not be enough incentive to complete it if
> all the parts are available under more or less proprietary
> licenses. Maybe I'm wrong, but your reasoning that it's OK for people
> who want games to have to pay for it certainly doesn't reassure me.

What I meant is that for people that play games might it might make
more sense to pay a monthly fee since most of them, I guess, lack
the knowledge to contribute to Wine anyway.

Companies wishing to use Winelib to port their productivity
application are not in the same situation, they have the
resources pay somebody to improve what they need or perhaps
even do it themselves. Sure they can also choose to pay
companies with business models like Transgaming but then they
become dependent on them to fix bugs in the extra parts they supply.

Actually, this is analogous to normal argument for using
open source instead of proprietary software, nothing 
that is unique to Wine.

In short:
The incentive is the same as working on any open source software.
Sometimes is makes sense, sometimes is doesn't.

> > In that case it would be disasterous to make Wine run
> > all Microsoft implemented non-core Wine DLL:s because
> > then everybody would just be happy to use the Microsoft
> > DLL:s and nothing beyond non-core would ever be
> > implemented.
> 
> It would not be a disaster, but it is certainly a potential problem
> too. It is a smaller problem first because making the dlls run is
> about as much work as reimplementing them, and because they are
> completely proprietary, not half-way open source. But yes, I do think
> a number of features could have improved faster if people didn't use
> native dlls to work around the problems.

There is a distinct possibillity that people used the time they didn't
need to reimplement the working Microsoft implemented functions to implement
functions that didn't work so it is quite hard to provide hard proof on
this.

Furthermore the fact that a lot of the Microsoft implement functions works
might instead have encourage people to work on because SOMETHING work
instead
of giving up then NOTHING worked.

In any case I think neither of us will be able prove the correctness of
our respective theory.