Kernel Traffic
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #283 For 15�Jul�2005

By Brian Vincent

Table Of Contents


This is the 283rd issue of the Wine Weekly News publication. Its main goal is to split aces. 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

Mailing List Stats For This Week

We looked at 178 posts in 819K.

There were 64 different contributors. 35 posted more than once. 38 posted last week too.

The top posters of the week were:

1. Direct3D Work

11�Jul�2005�-�14�Jul�2005 (5 posts) Archive Link: "wined3d - d3d9 regression testing"

Topics: DirectX

People: Nick Burns,�Oliver Stieber,�Jesse Allen,�Stefan Dosinger

Some weeks there's an overwhelming amount of threads on wine-devel and it takes a long time to summarize all of them. Last week wasn't one of those weeks. Most of the threads were pretty boring and few of them really touched on the development going on in the tree. There's definitely been a lot of CVS commits, so don't base development on the lack of mailing list threads.

More Direct3D 9 work has made it's way into the Wine tree. Oliver Stieber announced this week that Half-Life 2 will now run, however performance seems to be pretty bad and requires more work. More importantly, you can now run demos and check for regressions. Oliver described what he uses for that last week and we covered an abbreviated list in WWN #282. Nick Burns began running the demos and giving reports of how things were progressing. On Monday he wrote:

results of wined3d - d3d9 regression testing on windows98se gf4 4200 64MB (using wined3d+GLX->WGL patch)

General overview

You can find a complete description of how the demos ran in Nick's summary. Regarding the last item, Oliver knew of the issue:

The slowdown is caused by this patch:

I've been working on an improved version that looks up what the graphics card supports once and generates a lookup table for later validation which makes the checks more or less instant, but it's not quite yet ready yet.

Jesse Allen reported some realworld things were working better:

Just to let y'all know that I was able to get BF1942 to show the EA screen finally with yesterday's CVS. That's the first time I have got anything to show in that game.

Stefan Dosinger gave some tips for getting further:

wine BF1942.exe +restart 1

or remove the movies/ directory. A NoCD patch is needed for BF1942.exe, Mods/bf1942/mods.dll, Mods/Xpack1/Mod.dll and Mods/Xpack2/Mod.dll Then it should come up properly, with missing text(font problem?). Starting a game works for me, but the graphics are not correct(wrong textures, units only shown half)

2. File Locking

12�Jul�2005�-�18�Jul�2005 (8 posts) Archive Link: "file locking"

Topics: Filesystems

People: Brian Vincent,�Alexandre Julliard,�Robert Shearman,�Vitaly Lipatov,�Rob Shearman

I asked a question about Wine's file locking. There had been some discussion WineConf over it and I was kind of confused after doing some quick tests:

I've been playing around with file locking and Wine, namely the fact that Wine doesn't have any.

Is there any way around this, maybe placing the burden on a filesystem? If I wanted to share files between two different users (say with something dumb like file permissions 666), is there any way to prevent the two people from stomping on each other?

Alexandre replied:

Wine has quite a bit of it actually.

If you want mandatory locking then yes this has to be done at the filesystem level, by setting the proper mount option and permissions. man fcntl should give you the gritty details.

I clarified what I was wondering, " What I meant was if I'm on Windows and run Word it will warn me if another user already has the file open. It won't let me open it for writing, but I will have the option to open it read only. On Wine it'll just let me open and write to it regardless of what anyone else is doing to the file. Or am I overlooking something?"

Rob Shearman outlined the issues involved and where things were heading, " As much of the file locking as possible is done at the file system level, but the only filesystem that supports the Windows style locking semantics is smbfs. The rest we have to emulate in the wineserver. As the wineserver isn't shared between processes (Alexandre is doing work towards making this possible and I am doing work on the security side to make it safe to), the only other alternative is a shared locking server (as suggested by the Samba team). AFAIK, no one has started implementing their suggestion."

After a little more discussion, Rob updated the FileLocking wiki page with some of the info. Vitaly Lipatov wanted some input about having one wineserver synchronize locks:

I guessed it is not needed to communicate between servers... I think user program will calls shared wineserver directly.

I need to get worked shared wineserver ASAP and am ready to do some coding for it. Have you any instructions for me or I need to patching it as I see.

Alexandre didn't like the idea and suggested what he'd like to see:

I don't think a shared wineserver is the solution. Shared locking has to work on network filesystems too, so it needs to be based on filesystem locking. This is currently implemented for normal locks but not for sharing modes, though that shouldn't be too hard to fix.

Keep in mind that "shouldn't be too hard" for Alexandre is slightly more difficult for anyone else.

3. MS Services for Unix

10�Jul�2005 (3 posts) Archive Link: "FWIW, news of SFU and wine"

People: Wesley Parish,�Felix Nawothnig,�Microsoft

Microsoft's Services for Unix provides a lot of interoperability features for NT. Wesley Parish got them working with Wine just for fun:

I've installed MS SFU successfully. I can now use gcc under wine on Linux to compile source for Linux under wine on Linux ... ;) A bit bizarre, and a decidedly roundabout way of doing things, but what's a challenge for?

I had a go at installing the x-window-system-on-MS-Windows package shown but it halted with these error messages:

So at the moment I can't run X under wine on Linux just for the fun of it and the delight of saying I can ... ;(

Anyone got any ideas?

Felix Nawothnig was surprised, " Are the SFU not implemented on top of ntdll? Considering that we don't even have NtCreateProcess it's hard to believe for me that it works... "

4. Debugger on Solaris

9�Jul�2005�-�15�Jul�2005 (7 posts) Archive Link: "Debugger startup"

Topics: Debugging

People: Robert Lunnon,�Robert Shearman,�Mike Hearn,�Eric Pouech,�Rob Shearman

Bob Lunnon has been working on getting Wine's debugger to work under Solaris. He asked earlier in the week about some signal stuff:

To implement a Solaris debugger I have traced the wineservers startup and there is something I don't understand. I get the following stack trace:

bebugger_attach calls suspend_process then stop_thread

stop_thread sends a SIGUSR1 at the thread of interest. The result of this is that the thread is terminated and there is nothing to attach to....

Why is this SIGUSR1 sent ?

Rob Shearman explained, " It is the way suspending processes is done because the kernel doesn't allow us to do it. The handler should be installed in the file dlls/ntdll/signal_i386.c. You probably want to find out why it isn't being installed correctly."

Bob wanted to know why:

OK, what do you mean the kernel doesn't allow you to do that - Suspend a thread or ??? Why not just write a SIGSTOP

Anyway I think I have worked past this but I now have run into a problem whereby procfs returns EBUSY on a control file write to start or single step a process which should only happen if the thread isn't stopped. My code though indicates it is stopped (I test the threads status to find out before I issue the run)

Very Odd.

Mike Hearn described the difference:

SIGSTOP has process scope on NPTL, I think.

If SIGUSR1 isn't handled, then stuff will break mysteriously. Essentially all it does is block on a wineserver fd until the thread is woken up again. In future it'll also store the sigcontext so copy protection and such works.

POSIX defines two different user-defined signals that can be sent and caught be applications: SIGUSR1 and SIGUSR2. Wine currently uses both and there's a need for more. That may or may not have been what Mike was referring to when he said SIGUSR1 could also be used for the sigcontext. Discussion in the past focused on muxing the signals or some such action in order to get the desired effect.

Bob must have sorted out the issue because he seemed to get further along later in the week:

Well we are getting somewhere

When my test application segfaults the debugger attaches and runs through a number of debug events eventually ariving at a segfault

Problem is that the client program is stopped, probably on a segfault trace because I enable tracing (stops) on all machine faults and signals when I attached it (this allows my replacement for wait4 to find out if a fault or signal happened in the debuggee). Everything deadlocks then since the debugger never continues the program after the exception (Or perhaps the wineserver never gets a message to restart it)

Perhaps I don't understand the semantics of PTRACE wait4 interactions. Should I just let the app trap machine faults ?

Eric Pouech had some questions about it:

With regards to the first question, Bob answered, " Nothing, the client doesn't get restarted it is in state "stop" when I look at the process with ps"

He was going to investigate Eric's suggestion about ContinueDebugEvent and go from there.

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.