> Given the amount of progress Wine has made over the past year,
> it seems (to me anyway) that the time may be appropriate to
> try for Wine version 1.0.
Perhaps, but personally I see Wine version 1.0 more
like a marketing gimmick, not something that has
large technical advantages for users or developers.
Of course that doesn't mean that we shouldn't do it.
> I was hoping to spark a conversation on this topic, in two
> basic areas:
> 1. Should we do it? (If not, why not, and when?)
First of all Wine is not normal project. In normal projects
the conflict between more features and stabillity is very
mportant, so they usually have two trees stable and development.
In Wine, this issue is not at all that important.
Since the API:s are specified by Microsoft the
most work are not spend on inventing new features,
but rather on fixing bugs. Note that by bugs I also
mean implementations of previously not implemented
functions. Since they wasn't implemented they
didn't satisfy the documentation, and thus they
were buggy.
With that in mind most developers are not implementing
new feature and thus most fixes, with the exception
optmizations, should, if we have two trees, be applied to
both of them.
This makes having two trees less meaningful and creates
a huge adminstrative problem, especially if large
reorganizations are made in the developments tree.
What I am trying to say is not that shouldn't release
Wine version 1.0, but rather that we can't use the
development strategies used by other projects so
we should discuss very carefully on how we should
solve these kind of problems.
I do not currently have any good suggestions,
I will have to think about it some more.
> 2. What needs to be done before we can release Wine 1.0?
The most important one is address space separation.
Secondly we need to assure that all non-core dlls
doesn't access things outside each dll except through
standardized mechanisms. I think most problems of
these kind are fixed, but it is important that
all of them are fixed since it will allow us
to develop and test the core dlls separate from
the non-core ones.
> 2. Many sample applications compile and work with Winelib 'out of
> the box' (along the lines of the work that Francois
> Gouget is doing).
Seen from a marketing point of view this is perhaps the most
imporant issue. If we release Wine version 1.0, we need good
support for compile out of the box or at least for compile
with just a few changes.
This is because when we release 1.0 some companies that
previously wasn't intrested in Wine, because their
applications was of a kind where it is important that
Wine is correct since errors are not immediately visable.
In Corel Office for example you can see that you
document/picture etc is wrong on the screen or at
least when you print it and if you can't see the
error you don't care.
These companies would never dream of using Wine now
when it is alpha (or beta) and we defintely doesn't
want to scare them away because their application
doesn't compile "out of the box".
Speaking about "out of the box" compilation,
since most application are written in Microsoft
C/C++, Borland C/C++ or other non-GNU C/C++ compiler,
support for other compiler are important.
Eventhough Wine/WineLib itself could of course be
compiled with GNU C, in some cases this isn't possible
because of reasons like must link with certain "libc",
calling conventions etc.
