Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #95 For 13 May 2001

By Brian Vincent

Table Of Contents


This is the 95th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

Next week's issue will likely arrive on Tuesday, or possibly later depending on how many threads there are. I'll be on vacation next week. On a related note, does anyone have any suggestions as to what to see or do at Lake Powell, UT?

Mailing List Stats For This Week

We looked at 2 posts in 182K.

There were 2 different contributors. 13 posted more than once. 0 posted last week too.

The top posters of the week were:

1. Headlines

10 May 2001 (1 post) Archive Link: "A new vintage and some interesting press"

People: Gavriel StateeetimesCodeWeaversTransgamingTransGaming

Alexandre has unleashed a new snapshot unto the world. On Thursday Wine-20010510 was cut and made available. The source is available via http at or through ftp at

The main changes include:

Also out this week were a pair of interesting stories in the press.

The first one, from GameSpy.Com, is titled Ports vs. Wine. As Linux Today describes it, "GameSpy takes on the question of whether Linux gamers are better off waiting for Linux ports (which aren't as plentiful as many would like) or getting behind Wine. Includes commentary from Gavriel State of Transgaming, which is working on bringing DirectX to Wine; and an assortment of pro-ports people including Scott Draeker of Loki, who maintain that compatibility layers are bad news". This is what Gavriel had to say in the article:

TransGaming doesn't see WineX as competition for source level porting efforts from companies such as TribSoft and Loki. Rather the opposite: WineX compliments the existing Linux games market by keeping Linux users in Linux to play their games, even when the developer or publisher has decided against a direct Linux port. TransGaming is certainly not going to be spending any effort on games that have already been ported by Loki or TribSoft.

Keep in mind also that WineX can be used for source level compatibility (aka Winelib) to speed up the process of recompiling games using Linux-based compilers and development tools, and thus taking advantage of Linux-specific features where they make sense. In fact, internally we use the Winelib approach for regression testing with the various Microsoft Direct3D samples.

It's not an either/or situation. We'll see some games being played under the Wine binary loader, some ported"natively" to Linux using Winelib and some direct access to Linux APIs, and others rewritten from the ground up using APIs like SDL.

The true strength of Linux and Open Source lies in diversity and choice, and having multiple approaches to game portability is just one more aspect of that strength.

Also included in the article is a nice screenshot of Shiny's Sacrifice running with WineX.

The second article out this week is "Plug-ins to enhance browsers of Linux-based appliances" from EETimes. It starts off:

Looking to narrow the gap in features between Windows- and Linux-based platforms, CodeWeavers Inc. has developed a series of browser plug-ins such as Shockwave and QuickTime for Linux-based Internet appliances.

CodeWeavers' Crossover plug-in software, scheduled for a May 15 launch, will be offered to Internet appliance manufacturers building platforms that run Linux or any Unix-like operating system.

And then further down:

"In addition to the Crossover plug-ins, CodeWeavers plans this fall to launch Crossover display, which will let an Internet appliance start up a Windows application installed on a nearby PC with a click of a button, but without a Windows OS. And Crossover server, scheduled for release in mid-2002, is a complete Windows-compatible Linux-based server. "

2. doors IPC

8 May 2001 - 9 May 2001 (3 posts) Archive Link: "doors IPC"

People: Damjan LangoMarcus Meissner

Damjan Lango posted note about speeding up the wineserver:

Some time ago here was a discussion about speeding up the communication between the wineserver and the application with various kernel patches. I was reading "Unix Network Programming, volume 2 - IPC" and ran over a "doors" IPC api that is implemented on Solaris and has the lowest latency. According to the book it is ~3 times faster than pipe. Actual values for Solaris 2.6 in the book are: (in miliseconds)


There is also a link to a Linux implementation of doors on:

On this link you will find also more info on doors.

But according to the performance tests that the author made, the linux pipe is somewhat the same speed as doors so maybe it could be optimized more or maybe is Linux's pipe already so optimized that doors are unnecesary.

So what do you think, would this be useful for speeding up wine? I apologoize if you already know about this...

Marcus Meissner replied with:

What a coincidence ;)

I just did a patch changing the critical section handling to become more of a spinlock.

I have attached it. This should reduce the critical section based reschedules between:


Since critical sections are thought to be 'fast' and 'short time' locking primitives, and Win32 threads should not sleep in a critical section, we can just give up our timeslice and wait for the other thread that has the lock to continue.

This is a preliminary version, but it works. It uses 'LockSemaphore' as differentation between process-local and global critical sections.

It uses 'sched_yield', which is a POSIX feature, to give up the timeslice. How does one force a reschedule on another UNIX? Is


This patch can give spinning processes on SMP systems, but I do not consider this a real problem at this time.

I would like to know if there is something wrong with the concept ;)

At least winword feels a bit snappier now.

3. Helping with Wine

9 May 2001 (2 posts) Archive Link: "Re: where do I go to find out who needs help"

People: Francois Gougetcodeweavers

Sean Callahan sent a message that asked what could be done to help out with Wine. Francois Gouget sent a lengthy reply that listed a lot of items:

Hmmm, I think I can also find a list of bugs in bugzilla that could easily be fixed by someone new to Wine:


Medium (I expect these would take longer or be a bit harder)

But let us know also what kind of work you would like to do and what kind of things you're best at:

It also depends on what motivates you: getting an application to work, implementing some new functionality, getting applications to compile, fixing scripts, fixing documentation or writing new documentation...

And the last parameter is how much time you have for Wine work. In any case it's probably better to start with something simple to see if you like it.

And in a completely different thread it was asked how to submit code once something has been fixed. Francois also replied to that with:

> Have a look at

More precisely:

Should you run out of FIXMEs (!), don't hesitate to ask for ideas of things to hack on this list.

4. GDB Remote Debugging

9 May 2001 (4 posts) Archive Link: "GDB remote debugging"

People: Ove KaavenAlexandre JulliardOve KåvenEric Pouech

Ove Kåven posted a patch on the wine-patches list with updates on some code he wrote for using gdb to debug Wine apps:

For any sufficiently disillusioned Wine hackers, here's my current experimental code for letting GDB attach to a Wine process. It's reasonably featured (exceptions are caught, changing threads work, single-stepping works, software breakpoints work, you can do backtraces, change registers and variables, etc). You can also do "info shared" to get a list of loaded .sos, and use the "sharedlibrary" command to load their symbols, but I strongly recommend against loading symbols for, or you'll destroy the neat "info thread" display.

This code has helped me quite a bit in my debugging, actually, when winedbg couldn't be used...

Apply autoconf after patching. Engage with ./configure --enable-remote-gdb

I assume Alexandre isn't going to like some of the stuff in here, but I suppose it's up to him whether to take it or leave it...

He was right, Alexandre responded with:

How did you guess I wouldn't like it? ;-)

Actually I think it's a neat hack, but it doesn't belong in the server at all. You should be able to do the same thing as a client-side process using the Win32 debugging API. It could be either a stand-alone Winelib app, or a special mode inside winedbg so that you can reuse some of the code in there.

Ove responded to this and said that he could attach and detach gdb to a running process whereas the winedebugger can't do that. Eric Pouech cleared this up with some instructions:

> winedbg can't, at least nobody knows
> how to attach winedbg to a running process.

well, winedbg can... and now everybody *SHOULD* know

start winedbg without any argument on commande line then, use command

you'll get a list of running processes using the command

really attaches to the running process

the only drawback of the method (compared to gdb interface) is that the Win32 API doesn't allow to detach the debugger from a running process the only issue is to kill the debuggee (or the debugger)







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.