WWN Issue 39

This is the 39th release of the Wine's kernel cousin publication. Its 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:

CorelDRAW 9 ahead of schedule

This week, 105 posts consumed 322 K. There were 38 different contributors. 18 (47%) posted more than once. 17 (44%) posted last week too.

The top 5 posters of the week were:

14 posts in 65K by Patrik Stridvall
11 posts in 23K by Alexandre Julliard
11 posts in 27K by Huw D M Davies
7 posts in 13K by Ove Kaaven
5 posts in 14K by Uwe Bonnes

Wine in the press: the dark side	Archive
The week started with some negative readings on OsOpinion. Someone (Mr/Mrs Weston) posted an article 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
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: LWN LinuxToday Later on, Corel also announced the early release of Draw 9 for Linux, and attributed this to "sterling progress of the open source development project, Wine." Finally, Michael Cardenas announced that: Canvas7, a commercial graphics suite, has been ported to linux and is available for download now. . 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.

Wine in the press: may the force be with you

Some more bits on address space separation	04/17/2000	Archive
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: 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. and later on 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).

Archive

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

and later on 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
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: 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 Stridvall, who already tried to tackle the issue a while ago, fired again. He proposed several strategies, leading to different results: 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 extensions like _fullpath. 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. 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 three approaches. However, Alexandre Julliard quite didn't like them:I 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.

Winelib portability and #include

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: 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 Stridvall, who already tried to tackle the issue a while ago, fired again. He proposed several strategies, leading to different results:

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.

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

However, Alexandre Julliard quite didn't like them:I 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.

World Wine News