Wine Traffic

This is the 278th issue of the Wine Weekly News publication. Its main goal is to start on the seventh chapter. 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

IBM has been a long-time user of Wine. Internally they use it to support their Lotus Notes client among other things. They can hardly be considered a supporter of Wine though. In fact, they've deliberately gone out of their way to yank articles from their website discussing Wine and in general try to discourage its use. An article over at ARNnet discusses IBM's usage in an article titled, "IBM A Reluctant User of Wine Software". From that article:

But trying to get IBM to talk about Wine is another thing entirely. IBM executives declined to comment on the company's use of Wine for this article, and while the software is mentioned occasionally on IBM's Web site, it is generally not endorsed as a tool for moving Windows desktops to Linux. Last year, IBM raised eyebrows in the Wine community by pulling an article describing the use of Wine from its DeveloperWorks Web site.

....

...according to Scott Handy, vice president of worldwide Linux strategy with IBM. IBM wants to promote open standards, like the Web-based protocols used in its Lotus Workplace suite of collaboration software, rather than the Microsoft APIs (application programming interfaces) used by Wine, he said.

Wine is definitely IBM's dirty, little secret. It's strange how much trouble they go through to sweep it under the rug.

Over at linuX-gamers.net, Andreas 'GlaDiaC' Schneider put together a Steam/Half-Life2/Counter-Strike howto. Steam has been sort of working with Wine for a while, although there's been some difficulty getting it to run. The notable change with this howto compared to past attempts is that it's no longer necessary to install Internet Explorer. A bunch of native DLLs are still required and instructions for installing them are given.

The AppDB has seen even more improvements in the past few months. We've had a lot of bug fixes, fuzzy searching support added, category and application sorting by name, etc. As part of the Summer of Code program, Ed Mack asked last week if there was some work that could be done on the website. Chris Morgan thought it would be really helpful and replied with some ideas:

One thing I've been thinking about lately is allowing maintainers to handle screenshot and version submissions for the applications they maintain. The maintainer system has been a great success so far with over 150 applications maintained by users of the appdb. These maintainers reply to forum postings for particular apps, edit and update application howto's and descriptions, and can add screenshots without appdb maintainer interaction. This would take more load off of the highest level maintainers of the appdb who have to go through all screenshots and all new versions that have been submitted. Continuing this distribution of work to individual experts should let us provide more accurate and complete information.

Another task would be to overhaul the look and feel of the appdb. It looks a bit clunky in areas and I think with some polish it would be more pleasing to the eye and easier to maintain the look and feel.

We are looking for anything that makes the appdb easier and simpler to use and makes administration and the data contained in it more timely and accurate.

In a different email Ed referenced the AppDB to-do list. For anyone interested in getting involved, that list currently reads:

incorporate templates into appdb to simplify code, Jeremy says we can borrow from lostwages(winehq.org/cvsweb/lostwages) for this
check for existing email when user is creating a new account
add a system that will allow users to monitor an app without becoming a maintainer.
add wineversion, distro, source/package fields to the user_list table.
add wineversion, distro, source/package fields to the appComments table.
add new table for maintainer ratings. fields: userid, appId versionId, rating, wineversion, distro, source/package

Thanks to everyone who helps maintain the AppDB. It's grown a lot over the past year and really improved. If you run an app regularly with Wine, consider signing up to be a maintainer.

Graphics

Christian Costa sent a large patch in for Quartz and described it:

This wrapper only support rle, msvideo1 and mjpeg for now. To enable support for it, download the latest FFMpeg package, build it and install it. Also copy avcodec.h, rational.h and common.h into a ffmpeg directory created in a standard directory (/usr/include or /usr/local/include). Once done, run configure to detect the library and the headers. The library is static so there is no runtime dependency.

Supporting more video codecs through Quartz is obviously a Good Thing. A couple replied suggesting that ffmpeg be detected at runtime. Rob Shearman's reasoning:

I think it would be better to always register the CLSID_FFMpegVideoWrapper class and just make FFMpegVideoWrapper_create fail if the libraries or headers aren't present. This will allow people to install these at a later date and after a recompile have the filter working, without having to re-register the DLL. It will also have the advantage of decreasing the number of ugly ifdefs everywhere.

Joerg Mayer had a different reason:

I haven't looked at libffmpeg as a standalone library, but in case it's possible to do so, maybe runtime detection would be the way to go. That way wine binaries can be delivered without being patent challenged and video support can be added by just installing an additional dynamic lib.

Integration

Andi Mohr asked if anyone had tried out a patch he came up with last month to help with scheduling problems on Linux. He asked:

has ANYONE done any testing with my experimental SetThreadPriority patch which I mailed on May 15? So far I haven't received any replies, despite this probably being rather interesting, given that it is implemented by many of our winmm threads...

Or should this remain untested until I have a sizeable amount of time for testing myself during LinuxTag?

The patch from May required some work to set up properly, but has the potential to improve anything highly dependent on the scheduler, such as games. Andi described the patch:

That stuff will require a REAL self-made kernel, a -ck one with that improved scheduling and much better interactivity, probably best to grab the 2.6.11-ck8 patch version, from http://members.optusnet.com.au/ckolivas/kernel/

(normal kernels don't have non-root realtime scheduling, due to very tricky implementation of usually easily DoS-able realtime priorities)

You'd be able to test it now, with my very preliminary proof-of-concept patch that is attached (it's not tested since I currently don't know of any software/game that uses SetThreadPriority()).

Also, testing would best be done based on known-to-be-problematic games. If this patch together with a SCHED_ISO-capable kernel makes a real difference, then we have something that we should continue to work on.

OK, again, you need:

2.6.X-ckX kernel (the ones with SCHED_ISO, SCHED_BATCH support)
rather current (CVS) Wine, since it requires the SetThreadPriority patches in various multimedia/sound threads in Wine
my patch in that Wine
one or better several preferrably problematic game(s) with in-game lags or sound distortion etc. pp.

And of course you should first run the game *without* my patch, since the -ck kernel may very well significantly improve game behaviour anyway (or actually deteriorate it), so the test basis is VERY different from running a normal kernel and this should be taken into account properly, otherwise you can just bin those test findings. :)

I'm interested in test results from as many people as possible, preferrably people with a good (excessive?) gaming background ;)

The best result would be to have this patch dramatically improve lag or sound or graphics interactivity in games in a recent CVS Wine version on a -ck kernel, compared to exactly the same environment *minus* my SetThreadPriority() patch.

One last thing: you might have to change the unix_tid in the patch into unix_pid in case it fails with the unmodified patch.

Please report any changes you observe.

Anyone already running a -ck kernel, or someone who doesn't mind upgrading, can send their results to Andi.

Testing

It's generally agreed that it's bad to code something that specifically checks for a version of Windows. However, often that's the easy way to make something work. Paul Vriens asked this week about something like that:

I've just finished another test for NtQuerySystemInformation. In this test I test the structure SYSTEM_PROCESS_INFORMATION. The structure is however different for NT4.

If I add an osversion (> 4) check I can check the structure for W2K/WinXP and W2K3 and skip this structure-check for NT4 (for now).

Wine however defaults to Win98 unless I put in the config:


[AppDefaults\\ntdll_test.exe.so\\Version]

"Windows" = "winxp"

Is there another approach or will this test be accepted as is ?

Alexandre suggested, Ideally you should determine which structure to check by observing the function behavior, not by checking the Windows version. For instance if the structures have different sizes you can use the returned size to determine if you got the NT4 structure or the win2k one.

Project Management

Alexandre announced a committee had been set up to review submissions to Google's Summer of Code:

Just to let people know, we have now organized an "official" committee composed of Jeremy, Dimi, Lionel, Dan Kegel and myself. We'll be reviewing the applications that Google forwards to us. So now if your application gets rejected you know who's to blame ;-)

In a different thread, Dan Kegel gave an update on the number of applications received so far. Later statistics put the average at around 320 per day. All in all, there's going to be a lot of competition, which can only be a good thing for a lot of open source projects. The stats, as originally posted by Chris DiBona:

Google hasn't sent out any applications to the mentoring organizations (e.g. Wine) yet, but they did just release a breakdown of the number of proposals received for each project. The count for Wine is at 77! No idea how many of those will make it through the selection process, but at least a few ought to be good. Here's the full breakdown from http://groups-beta.google.com/group/summer-discuss/msg/fd9e7ed643a3514d :

Google has specified that sponsoring organizations must decide upon applications by June 24th. So by next week there should be some idea of how many applications were submitted and by the week after some decisions will likely have been made.

Ports

Sometimes things get posted to wine-devel that are borderline editorializing. A lot of the time those threads don't really make it into WWN, or if they do it's only the technical bits. Scott Ritchie posted something interesting this week and it's something worth thinking about. With Apple's move this week to Intel, there will almost certainly be an affect on Wine. It's way too early to say what that is and how it will come about. Scott did have some technical ideas about that and wrote:

After thinking about it a lot and discussing it extensively in IRC and with a few other knowledgeable people, I think it's time to share my economic analysis of the impact of Apple's decision to move to x86 as it relates to us.

In short, Apple's move is nothing short of a tremendous potential boon. Getting Wine to work on OSX-x86 is probably one of the easier projects to do, and most of the work has been done already by the Darwine project, such as a Cocoa layer in XCode for the various graphical pieces they've created.

While XCode objective C isn't importable to the main tree, most of Wine is portable to OSX-x86 very easily. X11, while not installed by default, works just as well on OSX as it does on Linux, and unlike most projects we don't need to worry too much about adopting the OSX look and feel, since we can't do that for applications that need to look and feel like Windows to behave properly.

That said, Darwine needs to remain a fork, though perhaps a more closely-related one. We might want to host or link them more from the main page. What's needed for Darwine that isn't needed for Wine are some OSX specific things - OSX doesn't use the freedesktop.org standards, for instance, so it will have to be specially coded for. I hope to soon be working on some of the freedesktop things for Wine (such as getting that infernal start menu working in Gnome), but that's a different matter for now.

Anyway, Apple's decision has fundamentally changed Wine's market environment in a way that's extremely friendly to us. With the Mac users going to Intel, the number of potential Wine users has somewhere between tripled and quintupled, and all we have to do to get them is some relatively easy Cocoa work that's mostly done already.

More economically visible than the user base, however, is the almost overnight growth in Wine's potential market Apple's decision has caused. Right now, there are quite a few small firms roughly the size of CodeWeavers that make a majority of their money JUST porting games from Wintel to OSX on PowerPC. As we know, porting these programs with Wine is far more efficient than rewriting the code from scratch to use completely different APIs, even if we have to expand Wine a little in the process. Moreover, as Wine gets better and better it becomes increasingly easier to port applications - I'm sure our users (and TransGaming's customers) wouldn't mind games working better in the free version of Wine. In economic terms, that not only means that our production technology is much better, it means we face increasing returns to scale: we can provide the same service cheaper, and the advantage is increasingly ours the more we do it.

Simply put, with Apple's move to x86 companies using Wine now have the potential to displace these small porting firms very quickly. Since CodeWeavers is currently the only company of Wine experts out there, I can't think of a better firm to enter this newly changed market. If I were CodeWeavers, I'd strongly consider investing in a Cocoa developer and a development kit, and put him to work making a Cocoa version of the CrossOver interface. At the very least, I'd give Apple a call and see if they have any desire to help.

And Apple should be helping a lot. Now, I can't be sure if CodeWeavers don't have a secret agreement with Apple already (it would certainly be Apple's style), nor can I be sure that Apple isn't already secretly forking Wine (much like they did with Konqueror). However, the point still stands - in about a year's time, when Macs on the x86 are being sold, Longhorn still isn't out, and Wine is a stable, functional, and usable piece of free software, things are really going to shake up.

Now, firms that stand to lose out by this shakeup may be in a bit of a daze right now. They might try and deny it will ever happen, claiming Wine will never be good enough, or usable enough, or whatever, but we can all see the writing on the wall from here - the Mac Porting firm is fundamentally doomed unless they embrace our new, cheaper technology. If I had a bit of capital or a rich friend, I might even buy one of those firms myself, turn them into Wine people, help perfect Wine's gaming support, and conquer the world of porting software to OSX on the cheap.

Being realistic, it's way too early to speculate on a lot of this stuff. Lots of conspiracy theories in the community about Apple and Intel are floating around, but the truth of it seems to be IBM couldn't produce a mobile version of the G5. We're likely a few years away from OS X on Intel being a viable platform with a large enough community for Wine to be actively used.

Meanwhile, Friday saw a group of hackers dusting off Quartdrv and trying to get some things working.