WineHQ

World Wine News

All the news that fits, we print.

04/10/2006
by Brian Vincent
Issue: 311

XML source
More Issues...

This is the 311th issue of the Wine Weekly News publication. Its main goal is to carve corn. 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, 252 posts consumed 434 K. There were 77 different contributors. 38 (49%) posted more than once. 36 (46%) posted last week too.

The top 5 posters of the week were:

  1. 22 posts in 21K by julliard at winehq.org (Alexandre Julliard)
  2. 15 posts in 21K by mike at plan99.net (Mike Hearn)
  3. 12 posts in 19K by rob at codeweavers.com (Robert Shearman)
  4. 12 posts in 27K by kernel at kolivas.org (Con Kolivas)
  5. 11 posts in 9K by dank at kegel.com (Dan Kegel)

News: Windows on Macintels Archive
News

It looks like Wine is on the radar screen for Mac enthusiasts. This week Apple announced Boot Camp to allow Mac OS X users on Intel to boot into Windows. That's all well and good, but Jason O'Grady over at ZDNet hopes a different solution will be available:

I'd prefer to run Darwine (a.k.a. Wine for OX) because it will allow me to run just the Windows applications that I want without Windows, but in the meantime Boot Camp will suit me just fine. Boot Camp will certainly be a boon for Intel Mac customers and is sure to drive sales of Apple's newest iron.

Personally, I think OS X support is one of the biggest things that could help Wine. For one, it doubles the potential number of users of both Wine and CrossOver Office. While that might not necessarily translate into more developers, it seems to be. Second, it also leads to advocacy, and that's certainly not a bad thing. Even if that's just someone writing in a blog wishing they could use Wine.

Jeremy White was interviewed by eWeek about the Apple announcement and said:

Now, however, White said, "sadly, it'll take a bit of the buzz out of our own Mac product launch [which is coming soon], but what the heck, we compete with dual booting on Linux OK."

He's said he's "not sure" what the overall effect Apple's move will have on CodeWeavers and the Linux desktop, but "I hope it means more people buy Macs; I crave a world with far more OS diversity than we have today."

Wired also reported about efforts to run Windows programs on the news Macs and Wine was mentioned.

Finally, there was some news about Wine being able to run PartyPoker . Running poker clients on Linux with Wine isn't exactly news, but it seems more and more people are discovering it. Check out the AppDB for a full list of poker clients and their status on Wine.


Microsoft WGA & Wine Archive

The Windows Genuine Advantage came up last year when it was discovered Wine was being searched for and denied access. See WWN issues #263 and #264 for the background on that. At the time there was a lot of speculation concerning whether Microsoft would allow application updates if they were running with Wine. Marcus Meissner discovered the answer in a Microsoft FAQ:

Just found by random web search...

...
Q: Will systems running WINE pass WGA validation?
A: Wine is an implementation of the Windows 3.x and Win32 APIs on top of X and Unix. When WGA validation detects WINE running on the system, it will notify users that they are running non-genuine Windows, and it will not allow genuine Windows downloads for that system. Users of WINE should consult the WINE community for WINE updates. It is important to note that WINE users, and other users of non-genuine Windows, can continue to download updates for most Microsoft applications from Microsoft application-specific sites, such as Office Update.

That's the second time Microsoft has acknowledged Wine. In fact I'd like to congratulate Microsoft for bringing up Wine two times more than IBM has in the past year. And guess which one relies on Wine internally to run its Notes client.

By the way, could one of you guys at Microsoft please get the FAQ changed to read "Wine " rather than "WINE "?


Audio Latency Issues Archive
Multimedia

Latency has proven to be a problem in Wine. Threading in Windows works differently than on Linux, so some programs expect to get a timeslice that's difficult to achieve on Linux. Probably the biggest area this affects is audio. So let's just skip to the end of the story that has a promising solution. After a lot of discussion, Con Kolivas suggested the solution is to use the new 2.6.17-rc1 kernel (or preferably wait for 2.6.17 to be released in a few months):

It's not ALSA vs OSS, but changes in the pipe code at about that time changed how tasks waiting on pipes were scheduled due to code by Linus and Ingo. Hence why I'm suggesting testing 2.6.17-rc1 because I noted this could cause scheduling problems and modified the code recently to fix this and it was pushed into 2.6.17-rc1. This should cause an improvement in latency with any tasks that wait on pipes.

Wine's audio happens to be one of those tasks that wait on pipes.

So how did the whole thread about latency in Wine's audio start? Mike Hearn posted a patch to get the sound in a game functioning and explained what it did:

This patch gives me rock solid audio in Imperium Galactica 2. No more white noise, clicking or destabilising halfway through.

It exposes a race that I'll send a fix for later, for now I am hacking around it with a sleep(1) at the end of RtlUserCreateThread. The race is that you can do this:

    hthread = CreateThread(...);
    SetThreadPriority(hthread ...);

and the set_thread_info server call will occur before the thread has fully initialized, so we don't know the UNIX tid and cannot set the priority. My current idea is to fix the race by forcing RtlUserCreateThread to wait for the thread to sync with the server using an event.

This patch only implements support for TIME_CRITICAL threads. Mapping priorities at a finer level of granularity is still on the todo list.

Final thing - there has been on/off discussion about the security implications of this in the past. But, this code needs to be implemented anyway, regardless of outcome, and, on SuSE at least, I think AppArmor can be used to allow for thread prio raising without full root access. So IMHO the permissions debate layers on top of this. Until an acceptable solution is found some users may wish to just run Wine as root and play their games, which they know are trustable.

Then in another patch he took into account whether the thread being accessed was time critical and if so it needed to use the SCHED_FIFO mechanism. What is SCHED_FIFO you ask? It's one of three different scheduling policies in the kernel, with the others being the default SCHED_OTHER (which Wine normally uses) and the round robin SCHED_RR. A process using SCHED_FIFO can be set up to always preempt a normal process using SCHED_OTHER. So when that process needs to run, it does. There's a caveat though: SCHED_FIFO requires root access.

Now, another alternative mentioned on the path toward a solution was to use Con's SCHED_ISO ('isochronous') policy which is a form of soft real time. The SCHED_ISO patches have been floating around for a few years, but unfortunately they're still not merged into the mainline kernel.

Alexandre wasn't in favor of adding SCHED_FIFO support since it required root access:

Until it crashes your box of course... I really don't think we want to encourage running as root, or give Windows apps a way to screw up the system. If we have to require people to upgrade their kernel to get the feature that's fine; at least then when the box dies we can blame the kernel guys ;-)

Mike tried to persuade him to accept the patch:

If a Windows program has a habit of hard freezing the system then the user will learn not to run that program.

As it is, right now _many_ games suffer this problem with corrupted audio and it's very unpleasant (loud bursts of white noise). Makes the games unplayable, in fact.

I'd rather make the games playable and give developers an incentive to find a better privilege model than leave this to coast along for another few years with only a bunch of talk, ideas and non-mainline patches.

Right now there are no good solutions for this we can implement in Wine itself (except maybe making wineserver suid root and drop privs), and SCHED_ISO isn't merged into the mainline kernel, so telling users to upgrade won't solve much.

I agree that it's not good, but this patch makes the best of a bad situation and it's better for the users this way. If they don't want to run as root, they don't have to, and if - like me - they know the game is safe and wish to have some fun this evening then they can.

Willie Sippel wondered if the solution was to use the low-latency JACK audio driver. Chris Morgan explained that wouldn't solve the problem:

Just using the JACK audio driver won't ensure that we won't see stuttering sound. If dsound is performing hardware emulation then it has its own internal thread that is performing mixing and other dsound events. If this thread gets held off then you'll have no sound to give to the jack audio driver when it runs.

Increasing the size of this dsound buffer and ensuring that it runs seems like the easiest ways to fix issues with the dsound thread being held off and should work for all audio interfaces assuming their threads also run reliably.

Willie played around and reported another way to do this without requiring root:

Just tested Mike's patch with realtime-lsm. Running Wine as regular user now gives perfect audio with no stutter for every application I tried so far. So yes, realtime-lsm actually does the trick - me happy! ;) I load realtime-lsm with "gid=18 mlock=1 allcaps=1" (gid 18 is audio), and set wineserver to root:audio. Easy solution, great results!

That's about when Con jumped into the conversation. He didn't think a lot of this stuff should be necessary:

SCHED_ISO is a stable, mostly realtime solution for normal users. The one scenario that SCHED_FIFO was required _over_ the capabilities of SCHED_ISO is only professional audio sampling/capture work where one process may require almost 100% cpu for bursts of many seconds. Therefore for audio playback, SCHED_ISO is more than qualified.

While I'm pleased that SCHED_ISO fixes the problem for many people on this thread, I have to tell you that it is not the solution to your problem for a number of reasons. My motivation for creating this scheduling class was for transparent realtime performance to be attainable for an ordinary desktop user without their knowledge or previous setup. The reason is that the current system for giving realtime privileges to ordinary users is complicated and not set up properly by hardly any distributions. This is the real time rlimits capabilities which is already in the kernel.

I do not believe you are going to need real time scheduling to get audio to work properly. This really is overkill in my opinion. However if you really want to go down this path you need to use the kernel infrastructure that is already in place. The realtime rlimits is there and works. Getting modern distributions to have it set up by default properly is the first challenge. I have not investigated to see who has done this, but if they are not then pinging the distribution maintainers or even helping them set it up is the thing to do here. Providing walk-throughs on setting it up (until the distros catch up) and using the system from within wine seems appropriate.

Con then went on to mention he had no plans to get SCHED_ISO into the kernel since realtime rlimits solves the same problem. After a bit of back and forth, Mike Hearn mentioned Wine's audio relies on a message pipe. That's when Con mentioned his solution above - try out the latest Linux kernel, 2.6.17-rc1. Tomas Carnecky did and reported:

Works _much_ better with 2.6.17-rc1(-g6246b612). Though I still sometimes hear 'spikes' or 'bursts' (short pulse, high frequency), don't know what produces them but it really hurts my ears, they usually appear when the CPU is under heavy load (when WoW loads world data from the harddrive or when I switch from/to the workspace where WoW runs, but here I suspect wine's window handling code to block somewhere for too long), but now much less now, in fact, it appeared only once/twice in 10 minutes playing which is really great.

So, that's where we stand. If you need an immediate fix and don't mind running as root, you could use Mike's patch. Otherwise, Alexandre isn't like to commit it so the next easiest solution is to begin using pre-release kernels until 2.6.17.


Coverity Scans Wine Archive
Debugging

This week Coverity announced Wine is now being checked for bugs. Some of you may have seen other news reports about Coverity and the ability to automatically uncover subtle bugs in large codebases. Originally referred to as the "Stanford Checker", Coverity is best known for its original work scanning the Linux kernel. Coverity's initial look at Wine uncovered 830 bugs. In just a few days a bunch of patches have rolled in and that number is currently down to 749. Ben Chelf from Coverity announced the news to the wine-devel list this week:

As some of you may have heard, last month Coverity set up http://scan.coverity.com as a site dedicated to scanning open source projects for defects. In just 1 month, over 4500 defects have been examined by various open source developers, and from what we can tell, it seems that there have been over 2500 patches to the scanned code bases! Due to popular request, I'm happy to announce that we've added Wine to the list of projects scanned on the site. For those of you not familiar with "scan" yet and by way of introduction ...

I'm the CTO of Coverity, Inc., a company that has technology that performs static source code analysis to look for defects in code. You may have heard of us or of our technology from its days at Stanford (the "Stanford Checker"). The reason I'm writing is because we have set up a framework internally to continually scan open source projects and provide the results of our analysis back to the developers of those projects. To see the results of the project, check out:

My belief is that we (Coverity) must reach out to the developers of these packages (you) in order to make progress in actually fixing the defects that we happen to find, so this is my first step in that mission. Of course, I think Coverity technology is great, but I want to hear what you think and that's why I worked with folks at Coverity to put this infrastructure in place. The process is simple -- it checks out your code each night from your repository and scans it so you can always see the latest results.

Right now, we're guarding access to the actual defects that we report for a couple of reasons: (1) We think that you, as developers of Wine, should have the chance to look at the defects we find to patch them before random other folks get to see what we found and (2) From a support perspective, we want to make sure that we have the appropriate time to engage with those who want to use the results to fix the code. Because of this second point, I'd ask that if you are interested in really digging into the results a bit further for your project, please have a couple of core maintainers and/or developers reach out to us to request access. As this is a new process for us and still involves a small number of packages, I want to make sure that I personally can be involved with the activity that is generated from this effort.

So I'm basically asking for people who want to play around with some cool new technology to help make source code better. If this interests you, please feel free to register on our site or email me directly. And of course, if there are other packages you care about that aren't currently on the list, I want to know about those too.

If this is the wrong list, my sincerest apologies and please let me know where would be a more appropriate forum for this type of message.

Mike Hearn registered for access, went through the bugs, and reported on what he found:

A few of these are more tricky. EG:

  • One was wrong, it didn't track the fact that the given variable was initialized by a subroutine
  • Another (missing NULL ptr check in LoadTypeLibEx) is right, but, I don't think we want to add lots of missing NULL arg checks in the public API implementations. An application will never pass NULL to this function directly as otherwise it'd not work at all, so, a crash with a NULL arg here probably is revealing some other bug.

    I'd rather it crashed cleanly in a debuggable way than silently return error code and continue, in other words ...
  • It has identified a codepath through the server window station code where a struct desktop could be dereffed without being initialized. But I am not sure if this codepath is logically possible. Somebody more familiar with that code (eg Alexandre) would have to check if it could actually ever be taken or not.
  • Some of these are bugs that aren't really a high priority, eg leaks in winegcc (which doesn't live very long anyway)

Still. A real treasure trove of data here. Thanks Ben!

Discussion then broke into a discussion of a few different classes of issues found and whether or not they were really bugs or just false positives triggered by the checker.


sft2ttf: Getting Rid of FontForge Archive
Fonts Build Process

Wine's requirement of FontForge has been a problem lately. Several "bug" reports have come in that have simply been caused by not having it installed when compiling. The issue has come up more than once a week lately. Mike McCormack asked for someone to step up and help remedy the situation:

Wine's build time dependency on FontForge is causing a bit of a problem, as can be seen by browsing the wine-devel archives for the last month.

I propose that a small sfd2ttf utility be written and used instead of FontForge to eliminate the dependency, and make everybody a little happier.

George Williams, the author of FontForge, is happy for us to use his code under LGPL, providing that we give the correct attributions. He'd probably like to sign off on the final code though.

Alexandre agrees with the idea of an sfd2ttf utility, and is likely to accept it into the Wine tree, provided that is small enough (read 1/2 files) and is appropriately cut down.

As I'm busy with my day job at the moment, we're only missing somebody to write it. Any volunteers?


DirectDraw Update Archive
DirectX Status Updates

If you've been watching wine-patches lately, you might have noticed Stefan Dösinger has been sending a lot of patches with header changes for Wine's Direct3D library, wined3d. He wrote in this week to describe what those were for and where things are headed with DirectDraw:

I thought I'd give an overview of the status of the ddraw merge. Well, basically it's progressing nicely, and the first huge part of the merge has been done. The necessary type changes were made to include/wine/wined3d_types.h and include/wine/wined3d_interface.h, so ddraw can now use the wined3d interface header.

I have uploaded an updated patch against Wine from yesterday, 23:30 to my website (http://stud4.tuwien.ac.at/~e0526822/ ). It contains a few fixes, like yet another refcounting cleanup (I hope that this works fine now :) ), and the performance issue on my radeon card, as well as the mipmap issues (all cards) are fixed :)

What is next? I will send patches which create the new WineD3D methods needed for ddraw. These patches won't contain the implementation, but just the entry in the vtable and a stub function. So if someone disagrees with a method, then we don't have to discuss about the bare existence of a method and its implementation at the same time :)

Additionally, I will now start writing a lot of test cases for all DirectX versions, with an eye for reference counting, in the hope that we can fix the refcounting crashes finally. I have a test for some unimplemented functions in my local tree too, like ProcessVertices.

Once the function stabs are in, and the tests show where we have to go to, I'll send the implementation of the functions. After that, all that is left is to merge the ddraw.dll code, but first some regression testing has to be done. I'll ask then for some testing help here and at wine-users, so we can catch regressions before they can occur :)

Thanks for all the help with testing and coding so far :)

Elie Morisse mentioned the new DirectDraw code doesn't show any performance improvement compared to the current stuff. Stefan replied that was intentional. Speed improvements will come once the merge is complete and the door opens to using accelerated OpenGL calls.


SourceForge Community Choice Awards Archive

Marcus also mentioned Wine had indirectly won an award for something that's in its infant stage:

The 2006 SourceForge.net Community Choice Awards have been announced ... and it seems the Desktop Winner is:

"WINE ..... for Darwin and Mac OS X"

Strangely enough, our project directly does not appear to be listed at all in the "Desktop" category.

Still considering whether to be sad or happy.

I have now added us to the "Desktop environment" category.


Cross Process Calls Archive
Architecture

Someone asked a question on wine-devel about some unimplemented functionality in Wine:

Could someone clue me in to just what this means and why it is:

    err:virtual:NtProtectVirtualMemory Unsupported on other process

A quick Google comes up that function is undocumented, so I don't have much info on it.

From the wine source:

    if (!is_current_process( process ))
    {
      ERR("Unsupported on other process\n");
      return STATUS_ACCESS_DENIED;
    }

And that's self explanatory, but why is it "Unsupported on other process"?

Rob Shearman briefly explained the error is correct. Each Win32 process corresponds to a process on Linux. The problem is getting those processes to talk to each other like they would in Windows. Wine can keep track of the processes and look them up to synchronize communication, but some parts of that are hard. Rob wrote:

There is already a lookup in the server, but there is no cross-process syscall for NtProtectVirtualMemory (and in fact for all of the other virtual memory functions). The cleanest fix is to get the kernel to support this. One suggested way of fixing this and other cross-process problems in Wine without kernel support is to change the context of the target process to set up a call to the relevant function and restore the registers afterwards. AFAIK, no one has tried to implement this yet.

Mike Hearn mentioned a system like that would help with other tough calls:

The wineserver would have to trigger some code in the client, either by having a signal or a generic background thread that could do it on behalf of the other process.

Such a scheme has been discussed before for things like CreateRemoteThread and friends.

That struck a chord with Stefan Dösinger and led him to ask:

That would be useful too for multithreaded direct3d. Somehow we have to bring another thread to releasing the glxContext, so we can re-use it in a new thread.

Any chance we can do this with signals? e.g. SIGUSER1 to call a wine-provided callback function, which calls callbacks registered by the various dlls?

Lionel Ulmer threw out an idea:

After discussing this at length on IRC with another coder, we think that the easiest solution would be to have one GL context per thread (and multiple contexts can share the same rendering target and also texture handles). If we add 'intelligent' (i.e. 'lazy' or 'just in time' :-) ) state change evaluation it could even be pretty efficient code-wise (maybe not so efficient in the GL driver though as it may lead to more 'pipeline flushes' than the 'hacky' solution). After we just have to rely that this is properly implemented at the GL driver level...

I once wanted to toy with this in the DDraw code base but well, seeing that it will be phased out pretty soon I did not do any work on it. On the other hand I could try for some specific games (like DungeonSiege) as an experiment to then port it over to WineD3D.


gPhoto & TWAIN Archive
Integration

TWAIN, the standard for image acquisition devices, has only been implemented for scanners in Wine. This weekend Marcus dropped a large patch to add support for gPhoto supported devices. Marcus has been a Wine hacker for over a decade and in the past few years has been actively working on gPhoto. In fact, if you've seen the annotated pictures from WineConf the past couple of years, they've been done by him. On Sunday he asked on wine-devel about his approach for Wine's TWAIN to access libghoto:

I have started adding gphoto2 support to twain.dll.

My current work (before an otherwise busy week begins again), is attached.

I started to break up the currently very sane centric view.

Alexandre/Aric, can I do it this way? Some other general comments?

(The code btw works as-is for detection at least.)


All Kernel Cousin issues and summaries are copyright their original authors, and distributed under the terms of the
GNU General Public License, version 2.0.