WWN Issue 283

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 www.winehq.org

This week, 178 posts consumed 819 K. There were 64 different contributors. 35 (54%) posted more than once. 38 (59%) posted last week too.

The top 5 posters of the week were:

15 posts in 52K by Oliver Stieber
14 posts in 35K by Alexandre Julliard
11 posts in 32K by James Liggett
10 posts in 117K by Nick Burns
8 posts in 23K by Robert Shearman

Direct3D Work 07/11/2005 Archive

Direct3D Work	07/11/2005	Archive
DirectX 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 its 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 some demos give odd crash on exit resizing windows is hacked (blame me) -- instead of stretching the output -- it simply changes the viewport size for programs that enumerate display modes the screen flashes a lot for programs that enumerate display formats it takes a LONG time to startup 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: http://www.winehq.org/hypermail/wine-patches/2005/04/0289.html 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 instantaneous, 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)

DirectX

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 its 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

some demos give odd crash on exit
resizing windows is hacked (blame me) -- instead of stretching the output -- it simply changes the viewport size
for programs that enumerate display modes the screen flashes a lot
for programs that enumerate display formats it takes a LONG time to startup

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:

http://www.winehq.org/hypermail/wine-patches/2005/04/0289.html

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 instantaneous, 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)

File Locking	07/12/2005	Archive
Filesystems 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 a working 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.

File Locking

07/12/2005

Archive

Filesystems

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 a working 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.

MS Services for Unix 07/10/2005 Archive

MS Services for Unix	07/10/2005	Archive
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: `[wparish_at_localhost sfu+X]$ wine x-win612LX.exe fixme:win:SetWindowTextA cannot set text "InstallShield Wizard" of other process window (nil) fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet. fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet. fixme:shell:SHELL32_DllCanUnloadNow (void): stub [wparish_at_localhost sfu+X]$` 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...

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:


[wparish_at_localhost sfu+X]$ wine x-win612LX.exe

fixme:win:SetWindowTextA cannot set text "InstallShield Wizard" of other 
process window (nil)

fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.

fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.

fixme:shell:SHELL32_DllCanUnloadNow (void): stub

[wparish_at_localhost sfu+X]$

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...

Debugger on Solaris 07/09/2005 Archive

Debugger on Solaris	07/09/2005	Archive
Debugging 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: `send_thread_signal+0x4a(80aab90, 10) stop_thread+0x1f(80aab90) suspend_process+0x4d(81c72a8) debugger_attach+0xf1(81c72a8, 81d1b58) req_debug_process+0x4c(81d1c38, 80477a0) call_req_handler+0x74(81d1b58) read_request+0x68(81d1b58) thread_poll_event+0x62(81d22b0, 1) fd_poll_event+0x14(81d22b0, 1) main_loop+0x9e(804785c, 8056a51, 1, 8047868, 8047870, 804785c) main+0xc6(1, 8047868, 8047870) _start+0x5d(1, 804795c, 0, 8047979, 80479f6, 8047a0a)` debugger_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 by 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: when you call ContinueDebugEvent, did you change the causes that caused the crash (from the debugger) ? If not, it should segfault again (but I don't know what happens) after you called ContinueDebugEvent, the debuggee should be restarted. It isn't the case, so I'd start looking at ContinueDebugEvent in the server so see what fails (you may want to start with breakpoints instead of seg faults, as it may be easier to handle - except for some kludges -> see winedbg/break.c, when incrementing / decrementing EIP) 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.

Debugging

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:


send_thread_signal+0x4a(80aab90, 10)

stop_thread+0x1f(80aab90)

suspend_process+0x4d(81c72a8)

debugger_attach+0xf1(81c72a8, 81d1b58)

req_debug_process+0x4c(81d1c38, 80477a0)

call_req_handler+0x74(81d1b58)

read_request+0x68(81d1b58)

thread_poll_event+0x62(81d22b0, 1)

fd_poll_event+0x14(81d22b0, 1)

main_loop+0x9e(804785c, 8056a51, 1, 8047868, 8047870, 804785c)

main+0xc6(1, 8047868, 8047870)

_start+0x5d(1, 804795c, 0, 8047979, 80479f6, 8047a0a)

debugger_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 by 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:

when you call ContinueDebugEvent, did you change the causes that caused the crash (from the debugger) ? If not, it should segfault again (but I don't know what happens)
after you called ContinueDebugEvent, the debuggee should be restarted. It isn't the case, so I'd start looking at ContinueDebugEvent in the server so see what fails (you may want to start with breakpoints instead of seg faults, as it may be easier to handle - except for some kludges -> see winedbg/break.c, when incrementing / decrementing EIP)

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.

World Wine News