Wine Traffic Brian Vincent

This is the 286th issue of the Wine Weekly News publication. Its main goal is to go to rodeos. 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
News Xandros News

We interrupt your regularly scheduled news of Cisco exploits to bring you this issue of the Wine Weekly News. We'll start out this week with a small news item of XYZ Computing's review of Xandros Desktop OS Version 3 Business Edition. For you acronym lovers, that's XDOSV3BE. There's a few paragraphs about CrossOver Office on page 4:

Using this tool I was able to install a number of Windows programs that I have stored on my C: in their executable form. Again, this may seem like the type of thing that a long-time Linux user would scoff at but if you are trying to move to Linux in a a gradual manner or you just happen to be attached to certain programs tools like this can prove invaluable. This process could be done in just a few clicks but took a good deal longer than a standard Windows installation due to the internal adjustments that must be made.

Wine's AppDB has continued to see steady improvements. Of course the goal is to make it easy to find applications, info on running them, and keeping everything up to date. Well, that in turn relies on application maintainers and requires some management infrastructure to be in place. Chris Morgan came up with a patch this week to give maintainers the ability to manage screenshots:

This patch should offload a little bit of the work involved in being an appdb admin by allowing maintainers and super maintainers to process screenshots submitted for applications they maintain or supermaintain, or to process submitted versions for applications they super maintain.

Any comments on the code changes? Ideas for improving the patch? I wanted as much review as possible for this one given that we are expanding the roles of maintainers.

ChangeLog:

    Chris Morgan
    Allow maintainers to process submitted screenshots and application versions for applications they maintain and supermaintain.

The AppdbInfo page on the wiki was updated this week as well. If you like to hack on PHP, you might be interested in looking at the to-do list.

Architecture

It's known there are performance issues with some sensitive areas of Wine. On Windows, calls between threads and processes can be handled really fast directly within the server. With Wine, those same calls require the wineserver to handle the synchronization, which itself is just another Linux process. Those roundtrip IPC calls to the server can be expensive, and a lot of work has gone into trying to make sure those roundtrips are minimized.

Oliver MÖssinger illustrated an example of a performance problem with a test program:

attached i have a test case whitch demonstates the differece between Windows and wine. There is also a sample program 'TEST.CPP' attached.

On Windows XP

  1. Start 'test.exe' from a dos-box... you see some FAST counting integers
  2. Start a other (loop.pl) program witch consumes mutch cpu time.
  3. the output of 'test.exe' is slower but FAST

On wine

  1. Start 'test.exe' from a dos-box... you see some FAST counting integers
  2. Start a other (loop.pl) program witch consumes mutch cpu time.
  3. the output of 'test.exe' is very slow

This different behavior starts from wine version 20041201. The version before was ok.

I have no patch and it would be nice if someone can write a patch to fix this.

In this case, Alexandre suggested fixing the app behind the test case (assuming there is one) rather than Wine:

You can probably fix it by passing PM_NOYIELD in the PeekMessage calls. But if your app needs a lot of CPU, restructuring the code to avoid all the needless polling would give much better results, and probably improve the behavior on Windows too.

Felix Nawothnig thought there was a real issue here that needed fixing:

That's just a workaround. Our PeekMessage is definitly misbehaving - I ran the attached test-program in Wine and WinXP... here are the results:

Wine:

    wine_at_majestix c $ wine foo.exe
    NtYieldExecution yielded 100 times
    PeekMessage(...) yielded 200 times
    PeekMessage(... PM_NOYIELD) yielded 100 times

WinXP:

    C:\>foo.exe
    NtYieldExecution yielded 100 times
    PeekMessage(...) yielded 0 times
    PeekMessage(... PM_NOYIELD) yielded 0 times

(The numbers slightly differ between runs for obvious reasons but they are close enough (with an error margin of +/- 10 we could maybe make this a real testcase))

So, PeekMessage always yields execution (it shouldn't) and without PM_NOYIELD specified it yields execution twice (although it shouldn't at all).

The (real) effect of PM_NOYIELD is described at

Alexandre asked for a real world case of an app misbehaving:

PeekMessage is going to call the server and wait on the result, there's no way around it. The extra yield is to avoid hammering the server with requests in stupid apps that constantly poll for messages, since a server call is much more expensive than a Windows system call.

This could certainly be changed, but it will require evidence that the changes help for common real cases, not just to make some artificial benchmark show better results.

Jeremy White jumped into the thread:

I can imagine a case where a bad programmer has two threads and depends (not intentionally, but through accident) on one thread starving the other thread of CPU time such that a race condition never occurs. I don't have an example, but I have seen behavior like that, notably with IE and PowerPoint (although I think the case was with some other signalling method, not PeekMessage).

Thus, I think it's reasonable to try to preserve relative timing on Wine as closely as we can, even if it creates some overall performance degradation for poorly designed apps. (Famous last words, I'm sure I'll shortly be screaming about why is Wine suddenly so slow *grin*).

Alexandre didn't agree:

Yes, but the thing is you can write bad code that works fine on Windows but chokes down Wine, because we spend so much more time inside PeekMessage. The yield is an attempt to fix this by penalizing badly written apps to prevent them from hurting well written ones.

The problem is that the poorly designed apps will hammer the server, which will cause a much bigger performance degradation in unrelated apps than what you'd expect simply by hogging the CPU.

Jeremy dug into it and several hours later reported his findings:

I dug into this a bit further. Felix, the extra 100 yields are coming from code I prompted, in ntdll/sync.c; if the return from an NtWait... is TIMEOUT, then we force a yield. (The thread that points to more info is here: http://www.winehq.org/hypermail/wine-devel/2005/01/0469.html)

If I back that down and apply your patch, I can get to 100/1/1. This also makes Olivers test program retain priority (rather than slowing to a crawl as it does today). In fact, it keeps too high a priority (the perl test is slow and jerky by comparison to the Wine one, instead of being relatively even as on Windows). I'd theorize that's due to the server calls; we smell like an X process so we get priority.

However, this makes it clear to me that the yield in message.c is largely moot; you need to remove both that one and the one in ntdll/sync.c to have any material effect on Wine timing with messages.

Further, while I've been wanting to probe that yield in ntdll.c further, I haven't done my homework yet, so I think maybe I'll shut up and slink back into my corner.

Felix had an idea of a way to improve performance using shared memory, shm generally would lower the cost of a server request and doing that extra yield would no longer be necessary (although we'd still have the other yield due to the request itself unless the queue is put into shm).

Alexandre disagreed, If you mean passing the parameters through shared memory instead of a pipe, then no, it doesn't really make a difference. The cost is not the few bytes we need to copy across, it's the context switches.

Configuration

Well, the configuration changes seem to have settled down. The config file has been gone for over a month, winecfg is the preferred method for making changes, but you can also run regedit or even hand edit the text-based reg files. Part of the growing pains have meant some of the lesser used options are now accessible only in the registry with the caveat that you have to know where to put them. George Lober asked last week about Wine's handling of fonts and anti-aliasing:

I have just updated my install of Wine and I notice that the config file is now deprecated, it doesn't get used. I want to turn off Wine Anti-aliasing. I was able to do it in the config file, but now I don't know. 'winecfg' doesn't have any such setting. Can it be turned off in the registry ? If so what is the setting ?

Huw Davies replied this week where those can be found now:

Add the values

    "ClientSideAntiAliasWithRender"="N"
    "ClientSideAntiAliasWithCore"="N"

to the key

    HKCU\Software\Wine\X11 Driver

George reported it worked.