Table Of Contents
|1.||3�Apr�2001||(1 post)||Wine speed-up (cont'd)|
|2.||11�Apr�2001||(2 posts)||VxD Information|
|3.||3�Apr�2001||(1 post)||T@x2001: Linuxport via Wine|
|4.||7�Apr�2001�-�13�Apr�2001||(8 posts)||Debugger startup|
|5.||10�Apr�2001�-�11�Apr�2001||(13 posts)||Debugging using thread ID's|
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 (mailto:email@example.com) 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 (mailto:vinn+NOSPAM@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
Mailing List Stats For This Week
We looked at 72 posts in 232K.
There were 22 different contributors. 11 posted more than once. 9 posted last week too.
The top posters of the week were:
1. Wine speed-up (cont'd)
3�Apr�2001 (1 post) Archive Link: "Speeding up wineserver syncronization objects with shared memory"
People: David Howells,�
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:
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, Section�#3� (6�Mar�2001:�Wine's speed up (cont'd))
2. VxD Information
11�Apr�2001 (2 posts) Archive Link: "VxD Information"
People: Maurice van der Pot,�Alexandre Julliard,�
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.
3. T@x2001: Linuxport via Wine
3�Apr�2001 (1 post) Archive Link: "T@x2001: Linuxport via Wine"
People: Joerg Mayer,�,�Brian Vincent
Joerg Mayer was browsing SuSE's German portal and discovered a port of the program T@x2001 using wine. Here's an English translation (http://babel.altavista.com/translate.dyn?urltext=http%3A%2F%2Fportal.suse.de%2Fde%2Fcontent%2Freports%2Ftax2001.html&lp=de_en) of German page (http://portal.suse.de/de/content/reports/tax2001.html) 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.
(ed. [Brian Vincent] 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..)
4. Debugger startup
7�Apr�2001�-�13�Apr�2001 (8 posts) Archive Link: "Debugger startup"
People: Eric Pouech,�Alexandre Julliard,�
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 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 $* "
5. Debugging using thread ID's
10�Apr�2001�-�11�Apr�2001 (13 posts) Archive Link: "Traces: fs -> tid"
People: Francois Gouget,�Alexandre Julliard,�
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."
Sharon And Joy