This is the 91st release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (a port of the Windows API to Unix-based operating systems).
As most of you may have noticed, Eric Pouech has stepped down from writing KC Wine. 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
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
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.
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.
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 occured. 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 $*
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.