Re: WineX and the AFPL

On Tue, 11 Jun 2002, Deven T. Corzine wrote:

> On Wed, 5 Jun 2002, Francois Gouget wrote:
>
> > Any developper that stops working on a domain in disgust or because he
> > feels his work is useless since it will soon be obsoleted will not
> > compensate by working on another area. Thus it is a total loss for the
> > project.
>
> True, if the demotivation effect slows their overall efforts, that's a
> loss.  However, it's probably a temporary loss, not a permanent one.

As you said, Windows (or rather the set of APIs used by Windows
applications) is not a stationary target. So even a temporary loss can
have significant effects.


> > If you think other areas are more important then I would encourage you
> > to advocate them on wine-devel. Explain why they are important, what
> > Wine has to gain from them, and generally try to convince others (while
> > staying within reasonable limits of course). When you do this, then you
> > will either convince developpers to switch to work on this area, or wou
> > will convince new volunteers to start working on Wine which is even
> > better.
>
> Yeah, or it could just as easily annoy developers to hear non-contributors
> "directing" them in what areas they should work on.  No thanks.

It is much less likely to annoy them that if you tell them they are
wasting their time working on the area they love.


> > And yet, Windows was available, Wine did not support DirectDraw or
> > OpenGL and still gamers cam and contributed to Wine.
>
> Hey, it was just a hypothesis.  Don't take it too seriously.

Then don't come up with ridiculous hypothesis that you present
seriously. Your intent could easily be misinterpreted.



> This is exactly the approach I would have taken with Wine.  Start with all
> the API documentation in hand, and implement it to the letter. Then, watch
> for discrepancies and discover where practice differs from theory, and make

I would still recommend to check early whether Windows really does
things the way the documentation says (and preferably test at least one
Win9x and one NT version). Otherwise you are going to waste a lot of
time.

What you say about how to implement standards makes sense, that's pretty
much the way I would do it myself. But in the case of Wine it is less
compelling because there is no independent standard and only
implementation.

Now I do think that it could be beneficial if someone would just say 'I
am going to implement dll foo from a to z'. But then I realize that the
timescale for a project would be quite long, that a lot of work would be
spent on APIs that are never used and that a lot of code would be
expended to conform to a documentation that does not describe what
applications expect. So testing is needed but how do you find the one
application that exercises the API you are implementing? Clearly this
method does not work so you have to resort to writing your own tests
which generates even more work. But then these tests could be very
useful to Wine later so they would probably be worth it. But you need a
test infrastructure and there was none (i.e. now there is one). So we
are going into the right direction. But the important thing to remember
is that neither way of doing things is the end all and be all of
development for Wine. You need both and it is not easy to say where the
balance lies (or even where the balance points to currently).


> > out not to be. There is no way the kernel developper can test his driver
> > with all the sound cards out there and it is only through the feedback
> > of occasional contributors that his driver can finally work on a large
> > enough portion of the soundcards out there.
>
> They're often stuck with complete reverse engineering, which makes their
> job even harder than Wine's.  At least there is documentation for the
> Windows API, even if it's not complete or always obeyed...

Not to criticize the kernel (or X11) hackers, but in many cases where
there is strictly no documentation, Linux has no driver. For instance I
would love to see hardware scaling for my laptop's NeoMagic graphics
card. But there is no documentation, and there is correspondingly no X11
driver that supports it.

That being said, their work is indeed very hard. But so is Wine's,
especially because very often (more than you seem to suspect) there is
no documentation at all. this is the case, for instance, for the
interfaces between dlls since these are not supposed to be used by
applications. Yet these interfaces are very important to Wine and there
are more than 10.000 APIs.


> > I don't think so. Microsoft has not come up with a compelling new API
> > which is as radically different as Win32 was from Win16. NT/2000/XP are
> > in that respect >90% identical to Win9x. The only 'threats' I see are
> > Win64 and .Net but I don't see these having an effect in the near term.
>
> It doesn't matter how much is identical.  What matters is the installed
> base of users.  Once Windows 95/98 users are a small minority (as 3.1 users
> are now), nobody will care about backward compatibility anymore.

Precisely, when that happens nobody will care about backward
compatibility anymore. But given the current Win 9x install base this
not going to happen any time soon, and it will not happen in a day
either. It will be agradual evolution that will give us the time we need
to adapt.

Furthermore, concentrating on Win9x compatibility and doing things the
Win9x way would be conterproductive as that is clearly not the platform
of the future. If tried to be too closely compatible with Win9x (e.g.
having a mixed 16/32bit GDI) we would end up having to do major
reorganizations when we later try to be more compatible with the NT
platform and we would have to throw away muh of our code. So we are
basing Wine on the NT architecture already, which a much saner
architecture anyway.


> Even if there's 90% overlap, it's still making the job harder.

If we already implemented the 90%, that only leaves us with 10% more to
do.


> Sure, everyone has different opinions on priorities.  However, few would
> argue against the goal of "run everything 100% as well as Windows 95 does".
> If I can take Windows 95a, install IE, DirectX and other upgrades from
> Microsoft, and run just about any application, it should be possible to do
> exactly the same thing with Wine.

No.

Many applications that specifically target Win9x rely on VxDs which have
to be loaded into the kernel. In Wine this would mean loading the VxDs
inside the Linux kernel which is clearly unacceptable and would be
outside the scope of Wine anyway (remember, applications, not Windows).
DirectX is an example of such an 'application'.

So it is better to focus on compatibility with the NT architecture
(which does not support VxDs), which is what we already do.



> All the models suck, each in
> its own unique way.  Offhand, I'm not sure WHO could navigate these waters
> and truly chart an optimal route.

Don't worry, nobody can. Not the developpers, not the marketers and not
even the users (who may not know what they want, want too little or too
much).


> Saying they're "second-class" isn't the same as saying they're not valued.

Please, check an encyclopedia and you will see that 'second-class' has
strong derogatory connotations.


> Good bug reports are valuable, but only if acted upon.  I don't know how
> well or poorly the Wine community acts on bug reports, but I know that it's

I agree. The Wine community has handled bug reports (at least those made
in the Bugzilla bug database) very poorly. Fortunately this has changed
in the past few months thanks to the wonderful job done by Andryi
Palamarchuk, Tony Lambregts and others.



--
Francois Gouget         [email protected]        http://fgouget.free.fr/
In theory, theory and practice are the same, but in practice they're different.