Wine Traffic #39 For 17�Apr�2000
Table Of Contents
This is the 39th release of the Wine's kernel cousin
publication. It's main goal is to distribute widely what's
going on around Wine (the Un*x windows emulator).
Several important announcements have been made this week:
Mailing List Stats For This Week
We looked at 105 posts in 322K.
There were 38 different contributors.
18 posted more than once.
17 posted last week too.
The top posters of the week were:
- 14 posts in 65K by Patrik Stridvall <firstname.lastname@example.org>
- 11 posts in 27K by Huw D M Davies <email@example.com>
- 11 posts in 23K by Alexandre Julliard <firstname.lastname@example.org>
- 7 posts in 13K by Ove Kaaven <email@example.com>
- 5 posts in 17K by Francois Gouget <firstname.lastname@example.org>
- Full Stats
Wine in the press: the dark side
�Archive Link: "osOpinion: Why WINE is a very bad idea"
The week started with some negative readings on OsOpinion. Someone
(Mr/Mrs Weston) posted an
explaining how bad an idea Wine is.
This, of course, drew a long list of constructed (and un-constructed)
answers covering a wide scope of feelings: from sarcasm to antipathy,
from sorrow for the author's under-information to disdain. No need to
bring up further, any decent reader (does Mr/Mrs Weston read this
weekly newsletter ?) has already gotten the picture.
Wine in the press: may the force be with you
�Archive Link: "WordPerfect Office 2000 for Linux Review"
Since Corel started shipping WordPerfect Office 2000 for Linux (based
on Wine code), there were a couple of reviews on the Linux community
web sites. Here are a few:
Later on, Corel also announced (http://www.zdnet.co.uk/news/2000/14/ns-14764.html)
early release of Draw 9 for Linux, and attributed
this to "sterling progress of the open source development project,
Finally, Michael Cardenas announced that:
Canvas7, a commercial graphics suite, has been ported to linux and is
available for download now. (http://www.deneba.com/dazroot/softlibs/cv7_linux/default.html
We want to express tremendous gratitude to all the wine
developers. With only minor modifications to wine, we were able to
port our entire application to linux in 6 months.
Some more bits on address space separation
16�Apr�2000�Archive Link: "Win4Lin... Re: OS Opinion ... etc"
David Elliot,�Alexandre Julliard,�
In the course of arguments regarding the above mentioned OsOpinion
article, some points arose regarding the support of the core native
DLLs (GDI and USER) with address separation in place:
About a month ago I toyed with the idea of a
native GDI, and from what I have seen on this list, it should be
possible simply by implementing a proper display driver. So does
anyone have any objections if I go ahead and see if I can hack
something out for a DISPLAY driver? Will more work need to be done to
get GDI to work right (for instance, does GDI make assumptions about
kernel or the VxDs loaded that simply cannot be implemented in Wine)?
Alexandre Julliard answered:
and later on
We can probably make native GDI work, but I'm not sure we want
to. Wine's strength is that it doesn't depend on native dlls and thus
can do things at an higher abstraction level; this allows us to do
stuff like -managed mode, which I think everyone will agree is better
than -desktop. Ultimately I hope that we can also support Qt/GTK for
even smoother integration in the Linux desktop.
While native GDI would of course be optional, I think supporting it
would add constraints on the rest of the code that would prevent doing
some more interesting things; the native USER support is already
imposing unnecessary constraints, and will probably get broken by
address space separation anyway.
The problem is that the native USER/GDI we could run are the Win95
ones; but it doesn't make much sense to support 100% compatibility
with the Win95 kernel, which is an monstrosity full of 16-bit and DOS
code. It is preferable to do things the NT way, as it is much cleaner
and maps better to the Unix API. But of course this means we can no
longer run Win95 GDI/USER, just like they cannot run under NT either.
Alexandre also explained his intention to rewrite the 16 bit task
support (closer to what NT does).
Winelib portability and #include
�Subject: "stdlib.h, string.h et al"
Huw Davies,�Patrik Stridvall,�Alexandre Julliard,�,�Patrik Stridval
Huw Davies opened a can of worms with a question on Wine's strategy
for handling the Windows and the Unix include files and of course the
discrepancies between the two:
Patrik Stridvall, who already tried to tackle the issue a while ago,
fired again. He proposed several strategies, leading to different
Windows has its set of 'standard' includes which differ somewhat from
glibc. For example wcslen in declared in string.h and wchar.h in a
Windows environment whereas glibc declares it only in
wchar.h. Therefore a program that under Windows might include string.h
will not cleanly compile as a WineLib program. Other examples of this
are additions to the standard such as _fullpath which is declared in
stdlib.h. How are we going to deal with this?
Another related question is winsock.h. Some of the standard socket
functions have different arguments than their unix counterparts
(eg. getpeername()'s 3rd arg is socklen_t * in unix and int * in
Windows). At the moment winsock.h includes the unix headers at the top
which means that these prototypes don't match the Windows ones. Should
winsock.h be rewritten to not include these headers?
Patrik went on with some detailed specifications (including some
tricks like rewriting part of standard header files, using the
#include_next GNU C extension...) for implementing each one of the
However, Alexandre Julliard quite didn't like them:
- The application can only call Windows API:s and can't easily be
extended to call Unix API:s as well.
- The application can, like Wine itself, call both Windows and Unix
API:s. (requires GNU C extension #include_next)
- The application can, like Wine itself, call both Windows and Unix
API:s, but can only with some change call special Windows extentions
Mode (1) means that the application includes special Wine versions of
stdio.h, stdlib.h etc.
Mode (3) means that the application includes the Unix versions of
stdio.h, stdlib.h etc, like we do now.
Making and application work in mode (2) and (3) will in most cases
mean that the application must be changed, but we should make as easy
possible to make the application compile under both Windows and
WineLib and thus making it possible to have a common code base.
don't see why header tricks would be necessary. If you use the Unix
libc you should be able to use the libc includes. The few extensions
like _fullpath can be put in a separate header, and all you do is add
a #include in the app; I don't think we need to setup a heavy include
infrastructure just to ensure that _fullpath is defined in stdlib.h.
And the places where the Wine and Unix headers are really different
(fd_set, wchar_t etc.) are the things you cannot use anyway.
A few persons (like Peter Hunniset, Patrik Stridvall) were in favor of
a "out of the box" compilation process for porting an application (you
don't need to change a single line), but Alexandre firmly ended the
thread by balancing the "little gain" of having some prototypes be
present at the right places with the amount of work and maintenance
required to achieve the goal.
Sharon And Joy