Re: WineX and the AFPL

On Thu, 13 Jun 2002, Francois Gouget wrote:

> 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.

This is true.

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

I never said any developer was wasting THEIR time, since they have to 
determine for themselves what constitutes value for how they spend their 
own time.  I said that it might waste time for the PROJECT goal of a 1.0
release.  This isn't the same thing.  While time spent in a certain area 
might fail to advance such a goal of the project as a whole, it's hardly 
wasted from that developer's perspective if they value that work.

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

It wasn't a ridiculous hypothesis, just a flimsy one based on just a few 
statements made in the context of a discussion, not buttressed by tons of 
incontrovertible facts to back it up.  But I thought THAT was obvious from 
the context it was presented in.  I guess not.

> 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.

That sounds like good advice.

> 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.

Well, to a certain degree, the "standard" is more accurately the "reference 
implementation" of an actual Windows release rather than the "standard" 
nominally set by the released documentation.  Unfortunately, unlike most 
normative reference implementations, Windows is opaque, which makes life 
more difficult.  Since the documentation is (hopefully) easier to implement 
(to the degree it exists) than reverse-engineering Windows, it seems best 
to start there at first.  But obviously you have to check the normative 
reference implementations (as you say, Win 9x & NT both) if you really want 
to be compatible with this de facto standard...

> 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.

An early goal might to be to implement 100% of some API, but maybe not in 
A-Z order.  It makes sense to start with the ones more likely to be used 
and/or those with cross-dependencies, to allow testing of the partial API 
sooner.  Still, any completely unimplemented API represents an area where 
there's work yet to be done...

> So testing is needed but how do you find the one application that 
> exercises the API you are implementing?

Trial and error.  If it's really difficult to find an application that uses 
a particular API, that's good reason to make it a lower priority than those 
that are common.

> 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.

If you're going to write your own tests, it's critical to test them on the 
normative reference implementations to make sure the tests match the actual 
behavior, rather than just the documented behavior...

> 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).

Like Mozilla, Wine is a huge, complex project with a highly ambitious goal 
that makes it very difficult to get anywhere near done.  Unlike Mozilla, 
there aren't hundreds of full-time paid developers working on Wine, as far 
as I'm aware.  Even with hundreds of developers, it took Mozilla 4 years to 
reach 1.0 -- Wine has been going for what, 9 years?  How many more years is 
it likely to take with the current level of effort to reach a 1.0 state?  
Will it be possible to keep up with the moving target?

I'm not belittling the efforts being made on Wine.  Far from it; they've 
been quite impressive.  It's just that it's an enormous project and a very 
ambitious goal, and I'm not sure how to achieve that without the kind of 
serious money that was thrown at Mozilla to make it possible before it's 
too late to successfully compete against Microsoft...

> 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.

This might partly be the "good enough" factor.  Many Linux drivers are 
written out of necessity -- once that graphics card works, even if poorly, 
necessity no longer applies, so things like hardware acceleration are more 
likely to take a back seat, unfortunately...

> 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.

In my mind, the true normative standard for Wine is the various reference 
implementations embodied in the available Windows releases.  I consider the 
documentation to be ultimately secondary -- effectively hints at how the 
reference implementations supposedly work.  However, documentation is bound 
to be more transparent and easier to understand than an opaque reference 
implementation, so you might as well start there anyhow.

> > 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.

With the release of Windows XP, it's been moving surprisingly rapidly.  
Since you basically cannot buy a computer with Windows 98 anymore (unless 
you're a corporate customer), and many people will have replaced their 
computers in the next 2-3 years, XP could make Win98 irrelevant about that 
quickly.  If Wine can match Win98 in a year, it could be well in time, but 
if it takes another 4-5 years, it may be too late.

> 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.

Well, you have the advantage that XP itself is based on NT, but that may 
leave you in a position of eventually having to match XP if your chosen 
architecture makes it hard to match Win98.  In that case, XP might have to 
be your goal, which may be even more difficult, as it has that much more 
development behind it on Microsoft's side...

> > 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.

But is that 10% stuff easy or hard stuff?

> > 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.

What's wrong with the notion of supporting VxDs?  If that's what it takes 
to get full compatibility, why not do it?  People who want to keep their 
kernel safe from tampering could stick with the NT limitations, but many 
people would rather allow the VxDs into the kernel level than dual boot.

Besides, Linux has loadable kernel modules -- is this really infeasible?

> > 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).

The irony is that each group tends to THINK they can.  Oh well.

> > 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.

So does "third world", but it doesn't make the description inaccurate.

> > 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.

Well, let's hope it just keeps getting better and better...

Deven