WWN Issue 91

This is the 91st issue of the Wine Weekly News publication. Its main goal is to reminisce. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org

As most of you may have noticed, Eric Pouech has stepped down from writing KC Wine / Wine Weekly News. I've enjoyed the updates for a long time, so I decided to take it over. For the next few weeks the publication schedule may be a little eratic as I work out the best days to get this out. I anticipate a weekly Sunday/Monday update, but we'll see.

Please pass along any comments / questions / concerns / gripes to vinn at theshell.com. As always, if you have a particular thread you to see covered let me know. I'd also appreciate any links to updated screenshots, product reviews, or any other interesting stuff.

This week, 72 posts consumed 232 K. There were 22 different contributors. 11 (50%) posted more than once. 9 (40%) posted last week too.

The top 5 posters of the week were:

14 posts in 33K by Alexandre Julliard
10 posts in 37K by eric pouech
6 posts in 19K by James Hatheway
6 posts in 26K by Francois Gouget
5 posts in 9K by gerard patel

Wine speed-up (cont'd)	04/03/2001	Archive
David Howells posted an update on his work designing the kernel module that will work with Wine. This thread has been covered in several past issues. The most recent addition is an API that will interpret wineserver messages. David writes: I'm currently performing a major rearrangement of the files that comprise the module: Splitting the current win32 API bits out of the same files that contain the actual object class implementations. Putting the core and the API's in separate subdirectories. Abstracting name support, so that the internal API takes an "object name" which the user API is responsible for extracting from userspace and converting from WCS/MBS as necessary. Fixing introduced bugs. This does not mean that I'm getting rid of the Win32 API I've already got! It will just be optional. To see some of the other discussions concerning the kernel module refer to issue #86 .

Wine speed-up (cont'd)

04/03/2001

Archive

David Howells posted an update on his work designing the kernel module that will work with Wine. This thread has been covered in several past issues. The most recent addition is an API that will interpret wineserver messages. David writes:

I'm currently performing a major rearrangement of the files that comprise the module:

Splitting the current win32 API bits out of the same files that contain the actual object class implementations.
Putting the core and the API's in separate subdirectories.
Abstracting name support, so that the internal API takes an "object name" which the user API is responsible for extracting from userspace and converting from WCS/MBS as necessary.
Fixing introduced bugs.

This does not mean that I'm getting rid of the Win32 API I've already got! It will just be optional.

To see some of the other discussions concerning the kernel module refer to issue #86 .

VxD Information	04/11/2001	Archive
Maurice van der Pot wrote, I'd like to get started on VxD support, but I'm unable to find any useful documentation on how it's implemented in Wine. I've been looking through the sources (e.g. vxd.c, wprocs.spec) but I can't find the connection between a call to int 2F and a call to the functions in vxd.c. Alexandre Julliard responded, The connection is through int 2f ax=0x1684 (in msdos/int2f.c), which does a GetProcAddress on wprocs and returns the vxd entry point to the application. The app then calls the corresponding vxd directly with a normal function call. VxD support has thus far been a problem. In Windows VxD's run in Ring 0 with all the associated privileges. So a badly behaving VxD could have the potential to crash a Linux box. This is no small undertaking. One work around is to find an NT version of the application requiring a certain VxD - then it will access a device through Windows APIs which can be added to Wine.

VxD Information

04/11/2001

Archive

Maurice van der Pot wrote, I'd like to get started on VxD support, but I'm unable to find any useful documentation on how it's implemented in Wine. I've been looking through the sources (e.g. vxd.c, wprocs.spec) but I can't find the connection between a call to int 2F and a call to the functions in vxd.c. Alexandre Julliard responded, The connection is through int 2f ax=0x1684 (in msdos/int2f.c), which does a GetProcAddress on wprocs and returns the vxd entry point to the application. The app then calls the corresponding vxd directly with a normal function call.

VxD support has thus far been a problem. In Windows VxD's run in Ring 0 with all the associated privileges. So a badly behaving VxD could have the potential to crash a Linux box. This is no small undertaking. One work around is to find an NT version of the application requiring a certain VxD - then it will access a device through Windows APIs which can be added to Wine.

T@x2001: Linuxport via Wine	04/03/2001	Archive
Joerg Mayer was browsing SuSE's German portal and discovered a port of the program T@x2001 using wine. Here's an English translation of German page complete with screenshots. As Joerg notes, The program should be more stable and faster. After reading the translation, it's also apparent that it suffers from problems that some other Wine ports seem to have - the lack of security precautions that are necessary on a multiuser operating system. <editorialize>Personally though, I just got done doing my taxes using a Windows-based product and I sure wish I had an option of doing it in Linux. I would have gladly forgiven some file permission problems in order not have to boot into that other OS. Any vendors out there listening? You've got 8 months to get your product ported..</editorialize>

Debugger startup	04/07/2001	Archive
Eric Pouech discovered some problems launching the debugger from a shell script. Namely, someone (IIRC Gerard) had issues when starting the debugger when an exception occurred. The setup was that the AeDebug registry key pointed to a shell script, which in turn, launched the real debugger (used to set up different context options, and such). After a short discussion with Alexandre the problem was found to lie in the way the arguments were passed. As Eric noted, it's better to use the name from the server because it may be a windows style one (whereas argv[0] is always a unix one). Alexandre responded with a solution, You can set WINEPRELOAD to make sure we load the right file; so the exec would be something like: WINEPRELOAD=winedbg.so exec wine $*

Debugger startup

04/07/2001

Archive

Eric Pouech discovered some problems launching the debugger from a shell script. Namely, someone (IIRC Gerard) had issues when starting the debugger when an exception occurred. The setup was that the AeDebug registry key pointed to a shell script, which in turn, launched the real debugger (used to set up different context options, and such).

After a short discussion with Alexandre the problem was found to lie in the way the arguments were passed. As Eric noted, it's better to use the name from the server because it may be a windows style one (whereas argv[0] is always a unix one). Alexandre responded with a solution, You can set WINEPRELOAD to make sure we load the right file; so the exec would be something like: WINEPRELOAD=winedbg.so exec wine $*

Debugging using thread ID's	04/10/2001	Archive
Francois Gouget posted a patch against the debugging framework that adds a debug channel called 'tid' which activates printing the tid as the first field of all traces. Actually, it might make sense to merge 'tid' with the 'thread' debug channel. The rationale being that it makes traces easier to read. The discussion generated 13 posts in a day and quickly turned into what the debugger semantics should be and if or how the output of other traces should be affected. Alexandre ended it with, I think we have now wasted enough bandwidth on this non-issue. The relay traces have always displayed the thread info, and will continue to do so. People who are morally offended by the extra 5 characters needed for the tid can hack their local tree, or learn to use sed/awk/perl.

Debugging using thread ID's

04/10/2001

Archive

Francois Gouget posted a patch against the debugging framework that adds a debug channel called 'tid' which activates printing the tid as the first field of all traces. Actually, it might make sense to merge 'tid' with the 'thread' debug channel. The rationale being that it makes traces easier to read.

The discussion generated 13 posts in a day and quickly turned into what the debugger semantics should be and if or how the output of other traces should be affected. Alexandre ended it with, I think we have now wasted enough bandwidth on this non-issue. The relay traces have always displayed the thread info, and will continue to do so. People who are morally offended by the extra 5 characters needed for the tid can hack their local tree, or learn to use sed/awk/perl.

World Wine News