World Wine News

All the news that fits, we print.

07/19/2002
by Brian Vincent

This is the 129th 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).

This week, 166 posts consumed 611 K. There were 56 different contributors. 29 (51%) posted more than once. 30 (53%) posted last week too.

The top 5 posters of the week were:

13 posts in 33K by Francois Gouget
11 posts in 26K by Steven Edwards
10 posts in 24K by Alexandre Julliard
9 posts in 30K by Eric Pouech
7 posts in 14K by Andriy Palamarchuk

News	07/11/2002	Archive
News Wine-20020710 fell out of the CVS tree last week. Alexandre noted the following: WHAT'S NEW with Wine-20020710: (see ChangeLog for details) DirectSound 8 and DirectInput 8 support. Many OLE improvements. Support for font downloading in Postscript driver. ALSA sound driver. More portability fixes, particularly for Sparc. Lots of bug fixes. Also worth noting is some of the attention the Wine programs are receiving. Rolled into this release is some attention for Notepad (it now uses the RichText edit control) courtesy of Andriy Palamarchuk. Eric Pouech also submitted a patch to begin resurrecting Winhelp, though it didn't make it into this release.

News

07/11/2002

Archive

News

Wine-20020710 fell out of the CVS tree last week. Alexandre noted the following:

WHAT'S NEW with Wine-20020710: (see ChangeLog for details)

DirectSound 8 and DirectInput 8 support.
Many OLE improvements.
Support for font downloading in Postscript driver.
ALSA sound driver.
More portability fixes, particularly for Sparc.
Lots of bug fixes.

Also worth noting is some of the attention the Wine programs are receiving. Rolled into this release is some attention for Notepad (it now uses the RichText edit control) courtesy of Andriy Palamarchuk. Eric Pouech also submitted a patch to begin resurrecting Winhelp, though it didn't make it into this release.

Using NT Pathnames	07/16/2002	Archive
Filesystems Mike McCormack submitted a patch implementing some filesystem functions on public windows shares. Eric Pouech responded, I think the FS implementation gets more and more awful we need to structure it a bit more (like introducing a real FS driver model in Wine, and then implement several drivers DOS, SMB...) comments are welcome Obviously Mike had thought about this too and replied with some ideas: I agree with you, the FS implementation is a total mess. My thoughts for the FS implementation are this: Modify the wineserver interface to pass NT pathnames. Wineserver will decide what is a device, a path etc. One possible exception is UNC path names. (preliminary patch already posted to wine-patches) In the client side, convert dos path names, device names and any other filenames to NT path names. Call NTDLL functions only and let NTDLL talk to the server. Kernel32 should contain few or no server calls. The server should decide whether the file is a device or a normal disk file. eg. CreateFile("COM1:") -> NtCreateFile("\Devices\Serial0") -> server CreateFile("A:) -> NtCreateFile("\Devices\A:") -> server CreateFile("C:\xyz.txt") -> NtCreateFile("\Devices\C:\xyz.txt") Implement "a real driver model" in the client side for dealing with ReadFile, WriteFile, delete, rename, SetFilePointer, etc. Probably a structure containing function pointers for each operation, which can be registered with the client and referred to from wineserver by an index. Make directories use real server handles, rather than pointers to client structures. NtCreateFile supports taking a directory handle and a relative path name from that directory to open files. I've tried to keep my SMB implementation separate from everything else to facilitate this. As you probably know, I've been working on #1 (see my patch from a few weeks ago). Dmitry Tmishkov has also been doing some work to unicodify the entire file API. His work should be available in two weeks or so. The blocker for #1 is to convince Alexandre that NT really deals with paths the way my patch does... which involves writing some test programs on NT. We need to understand the NtQueryDirectoryFile function in more detail to do this.

Using NT Pathnames

07/16/2002

Archive

Filesystems

Mike McCormack submitted a patch implementing some filesystem functions on public windows shares. Eric Pouech responded, I think the FS implementation gets more and more awful we need to structure it a bit more (like introducing a real FS driver model in Wine, and then implement several drivers DOS, SMB...) comments are welcome

Obviously Mike had thought about this too and replied with some ideas:

I agree with you, the FS implementation is a total mess.

My thoughts for the FS implementation are this:

Modify the wineserver interface to pass NT pathnames. Wineserver will decide what is a device, a path etc. One possible exception is UNC path names. (preliminary patch already posted to wine-patches)

In the client side, convert dos path names, device names and any other filenames to NT path names. Call NTDLL functions only and let NTDLL talk to the server. Kernel32 should contain few or no server calls. The server should decide whether the file is a device or a normal disk file.
eg. CreateFile("COM1:") -> NtCreateFile("\Devices\Serial0") -> server
CreateFile("A:) -> NtCreateFile("\Devices\A:") -> server
CreateFile("C:\xyz.txt") -> NtCreateFile("\Devices\C:\xyz.txt")

Implement "a real driver model" in the client side for dealing with ReadFile, WriteFile, delete, rename, SetFilePointer, etc. Probably a structure containing function pointers for each operation, which can be registered with the client and referred to from wineserver by an index.

Make directories use real server handles, rather than pointers to client structures. NtCreateFile supports taking a directory handle and a relative path name from that directory to open files. I've tried to keep my SMB implementation separate from everything else to facilitate this.

As you probably know, I've been working on #1 (see my patch from a few weeks ago). Dmitry Tmishkov has also been doing some work to unicodify the entire file API. His work should be available in two weeks or so.

The blocker for #1 is to convince Alexandre that NT really deals with paths the way my patch does... which involves writing some test programs on NT. We need to understand the NtQueryDirectoryFile function in more detail to do this.

AppDB Hits 1000 Entries	07/12/2002	Archive
Project Management Andreas Mohr reported, I just wanted to let you know that the appliation database (http://appdb.codeweavers.com ) just managed to reach 1000 entries !! Roland pointed out that it would be better if there were a 1000 apps that worked flawlessly. Francois Gouget provided a link to the apps that work the best: Look for applications with a rating of 5. For instance in a fake_windows configuration: [ link ] And remember, preventing rating inflation is the responsibility of everyone.

AppDB Hits 1000 Entries

07/12/2002

Archive

Project Management

Andreas Mohr reported, I just wanted to let you know that the appliation database (http://appdb.codeweavers.com ) just managed to reach 1000 entries !!

Roland pointed out that it would be better if there were a 1000 apps that worked flawlessly. Francois Gouget provided a link to the apps that work the best:

Look for applications with a rating of 5. For instance in a fake_windows configuration:

[ link ]

And remember, preventing rating inflation is the responsibility of everyone.

Configuring for Sparc Solaris 07/17/2002 Archive

Configuring for Sparc Solaris	07/17/2002	Archive
Integration Shachar Shemesh tried to compile Wine on Sparc Solaris 2.8. He reported a lot of problems trying to configure it that were similar to: `checking resolv.h usability... no checking resolv.h presence... yes checking for resolv.h... yes` Francois Gouget explained: It means that: `#include <resolv.h> int main() { return 0; }` does not compile, but that `/usr/include/resolv.h` exists. In other words, resolv.h depends on other headers that you must include before including resolv.h itself.` So to have a clean configure, the above header must be moved out of the big AC_CHECK_HEADERS and into their individual checks where we can specifically test for these dependencies. See for instance XShm.h (only a vague quide). Shachar explained exactly why he was trying to get Wine to work on Sparc: I'll try, but I only have solaris machines at work, and this is far from my main focus on Wine (I'm working on BiDi, if you remember correctly ;-). I am only looking into solaris at all because at work we use some windows compat library for solaris (don't remember the name, but it wasn't mainsoft's) for the GUI part of the product. I am sprinkling the idea to the Unix GUI team here to check Wine out. The response so far has been moderately positive. (using those compat libraries incurs a non-trivial per-seat license that goes to MS, as well as horrible support. They have been complaining that response time on one incident was ONE YEAR!!!! and the idea of having the sources to the library itself were appealing to them). The main problem was that it would take over two days of effort just looking into it, and they cannot spare the time. Francois just suggested hacking the autoconf script to get it to work. Gregg Mattinson mentioned he might have some time to work on the Solaris issues. Two hours later he replied with a patch and noted, This patch fixes the configure problems reported to wine-devel by Shachar Shemesh. I have only tested it on sparc/solaris. This patch must be applied after my __sparc__ not defined patch sent to wine-patches on July 17. Francois tested it on FreeBSD and reported configure warnings on that platform also went away.

Integration

Shachar Shemesh tried to compile Wine on Sparc Solaris 2.8. He reported a lot of problems trying to configure it that were similar to:


	checking resolv.h usability... no

	checking resolv.h presence... yes

	checking for resolv.h... yes

Francois Gouget explained:

It means that:


   #include <resolv.h>

   int main() { return 0; }

does not compile, but that /usr/include/resolv.h exists.

In other words, resolv.h depends on other headers that you must include before including resolv.h itself.` So to have a clean configure, the above header must be moved out of the big AC_CHECK_HEADERS and into their individual checks where we can specifically test for these dependencies. See for instance XShm.h (only a vague quide).

Shachar explained exactly why he was trying to get Wine to work on Sparc:

I'll try, but I only have solaris machines at work, and this is far from my main focus on Wine (I'm working on BiDi, if you remember correctly ;-). I am only looking into solaris at all because at work we use some windows compat library for solaris (don't remember the name, but it wasn't mainsoft's) for the GUI part of the product. I am sprinkling the idea to the Unix GUI team here to check Wine out.

The response so far has been moderately positive. (using those compat libraries incurs a non-trivial per-seat license that goes to MS, as well as horrible support. They have been complaining that response time on one incident was ONE YEAR!!!! and the idea of having the sources to the library itself were appealing to them). The main problem was that it would take over two days of effort just looking into it, and they cannot spare the time.

Francois just suggested hacking the autoconf script to get it to work. Gregg Mattinson mentioned he might have some time to work on the Solaris issues. Two hours later he replied with a patch and noted, This patch fixes the configure problems reported to wine-devel by Shachar Shemesh. I have only tested it on sparc/solaris. This patch must be applied after my __sparc__ not defined patch sent to wine-patches on July 17.

Francois tested it on FreeBSD and reported configure warnings on that platform also went away.

Memory Handling Problem Found	07/18/2002	Archive
Memory Management Max wrote in with a detailed bug report after finding VirtualQuery() turned up a memory handling problem: As usual, AutoCAD seems to be a good test-bench for wine :-) I spotted the problem that seemed coming from VirtualQuery function, but that is (I guess... hmmmm) more a problem of memory handling in wine. Attached is the test source (compiled in Borland CBuilder, but should work with any compiler, apart some unuseful pragma's). If needed I can post the compiled too :-) To get around the particular problem he was having he made AutoCAD 2000 think it had a different protection flag. Andreas Mohr provided more information regarding the problem, PE files don't get their image mapping done correctly (i.e. wrong page protection flags for various memory image sections). I once tried to fix it, but it turned out to be a bit problematic (crashes), so I gave up on it again. See relevant code in loader/* (probably pe_image.c).

Memory Handling Problem Found

07/18/2002

Archive

Memory Management

Max wrote in with a detailed bug report after finding VirtualQuery() turned up a memory handling problem:

As usual, AutoCAD seems to be a good test-bench for wine :-) I spotted the problem that seemed coming from VirtualQuery function, but that is (I guess... hmmmm) more a problem of memory handling in wine.

Attached is the test source (compiled in Borland CBuilder, but should work with any compiler, apart some unuseful pragma's). If needed I can post the compiled too :-)

To get around the particular problem he was having he made AutoCAD 2000 think it had a different protection flag. Andreas Mohr provided more information regarding the problem, PE files don't get their image mapping done correctly (i.e. wrong page protection flags for various memory image sections). I once tried to fix it, but it turned out to be a bit problematic (crashes), so I gave up on it again. See relevant code in loader/* (probably pe_image.c).

All Kernel Cousin issues and summaries are copyright their original authors, and distributed under the terms of the
GNU General Public License, version 2.0.