Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #303 For 22 Jan 

By Brian Vincent

Table Of Contents


This is the 303rd issue of the Wine Weekly News publication. Its main goal is to paint. 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 570 posts in 1332K.

There were 148 different contributors. 87 posted more than once. 60 posted last week too.

The top posters of the week were:

1. News: Wine 0.9.6 and CrossOver Office 5.0.1

(4 posts) Archive Link: "News"

Topics: News

People: CodeweaversCodeWeaverscodeweaversWineHQSlashdotNewsMarcus Meissner

It's been a few weeks since the last WWN. Sorry about that, real life has been pretty hectic, not the least of which is because of snow. See, I tend to ski a lot in the winter and this happens to be the best year in Colorado in practically 30 years. Needless to say, I've gotten my fair share of days in this year.

We return this week with an attempt to catch up on some of the development that's occured.

First, let's take a look at the recent Wine snapshots. As we noted in the last issue (WWN #302), we're now on a shorter release schedule. Alexandre is putting out new snapshots approximately every 2 weeks. Wine 0.9.5 came out on January 4th with the following changes noted:

This week on January 19th another release came out with these additions:

As usual, you can download the source code from SourceForge or check out the WineHQ download page for a list of binary packages.

We'll go into more detail below, but we made headlines on Slashdot for the Windows Metafile exploit. Ironically, Marcus Meissner already had a patch available for Wine before the headline even appeared.

Finally, CodeWeavers has released version 5.0.1 of CrossOver Office. This is a maintenance release for version 5.0 and just contains bug fixes. From the announcement:

We had a number of minor glitches that we felt were important to release to our customers.

These include fixes for Notes (bouncing windows), fixes for Office install issues (e.g. spellchecker), and a lot of other minor problems that bothered us; a full changelog is included in this email, below.

It also includes a fix which prevents the EMF exploit from working in Wine; many thanks to Marcus Meissner for his speedy fix to Wine to that end.

We have a fix for ipod support that we decided to exclude from this release because we worried that it might break other programs. However, we are going to put up a FAQ on our web site in the next day or two to give interested customers a workaround.

As always, if you are happy with your current version of CrossOver, please do not rush out to upgrade to version 5.0.1. However, we did take some care to make 5.0.1 a nice stable upgrade, so it should be safe.

I'd like to thank the many people that helped with this release, including our customers, with their excellent problem reports, our beta testers (thanks guys!), the broader Wine community, and especially to Andrew Bogott, for his diligent and somtimes lonely work on seeing this release out the door.

Any CrossOver Office user can download the new release as long as their subscription is up to date.

2. Metafile Exploit

2 Jan  - 3 Jan  (3 posts) Archive Link: "RFC/PATCH: avoid metafilevirus problems"

Topics: Security

People: Marcus Meissner

Did you read about Windows metafile exploit? The issue at hand lies with Windows Metafiles, which are basically scripts for executing graphics commands. You can use them to create vector graphics by using commands to draw lines and fill rectangles and other such things. WMF files also support the SetAbortProc API that allows Windows to execute code stored in the WMF after the function is called. That's bad. For more details, check out the original CERT advisory.

Well, apparently it existed with Wine as well, although it's unclear whether or not it could be exploited. Even if it could, the arbitrary execution could only run with the same privileges as the Linux user running Wine.

Marcus Meissner posted a patch for Wine and asked for comments:

This patch reduces the attack vector on metafiles.

I originally wanted to filter only SETABORTPROC, but there are a lot of things that might be used to inject code.

Marcus' changelog entry for the patch said, " Only allow whitelisted escape codes when playing metafiles."

So while SetAbortProc started the while thing off, Marcus' final patch took into account other problematic calls. The patch made it into Wine and CrossOver Office 5.0.1.

3. Updated Benchmarks

(10 posts) Archive Link: "Benchmarks for 0.9.5"

Topics: WineHQ

People: Tom WicklineChris MorganWineHQMark

Tom Wickline has been benchmarking Wine for a little while now and posted some new results this week on the wiki. The new results are side by side by side XP SP2. Tom's brief announcement read:

Please take with a large dose of salt.

Chris Morgan pointed out Wine appeared to be doing better, " We appear to be faster now, leading in 67 tests vs. 63 for a previous set of benchmarks? Its difficult to see the trend over time having to go back and forth between pages."

There were some suggestions for improving it and Tom made some of the changes. The page eventually got linked to by Linux Today. There's a lot to look at on that page, so I'll leave it at that. You'll notice Wine does quite well, better than XP, on things like memory and filesystem access. That's proven to be true with other benchmark programs as well. The interesting results are in the 3D tests. Whereas Wine couldn't even perform many of the tests in the past, we're now faster than XP on many.

4. Patch Statistics

2 Jan  - 3 Jan  (2 posts) Archive Link: "Some patch statistics"

Topics: Status Updates

People: Hans LeidekkerCodeWeaversMichael Stefaniuccvs

Hans Leidekker went through the new git repository and generated some patch statistics:

I was curious how we did last year so I dug up some numbers with the help of git. I counted patches applied to the tree starting from 1999:

This is almost too good to be true isn't it? I worried for a while that these figures might be influenced by the switch from cvs to git, e.g. that cvs history somehow shows up compressed in git. On second look though it really seems that the past year has seen an impressive increase in productivity, compared to the previous years.

Michael Stefaniuc mentioned the numbers could be checked against the mailing list archives. Intuitively you can read some into the numbers above. In early 2001 we saw a dropoff in patches as Corel dropped their involvement with Wine. Things picked up again as CodeWeavers came on the scene. There really has been an increasing amount of activity and no one would deny that 2005 was a huge year for development.

Will 2006 be more of the same? Well, there's no reason to think otherwise and there's plenty of work to be done.

5. ntoskrnl.exe Status

(1 post) Archive Link: "ntoskrnl status with patch against wine-0.9.6"

Topics: Status Updates

People: Vitaliy Margolen

Whither ntoskrnl.exe? A lot of work has gone into supporting Safedisc and getting a ntoskrnl.exe working with Wine to load the driver it requires. In fact, it's probably the single biggest chunk of work that's been pending. A lot of that work requires more changes within Wine in order to be merged properly. Until then, it's living outside of the main tree. Vitaliy Margolen is maintaining it, or, at least keeping it on his hard drive. He gave a bit of an update this week on what's going on:

I'm sure number of people wonder where did ntoskrnl go. It's still here in the too hackish form to be committed.

For the past month it didn't even compile because of all the changes to different parts of Wine. I just thought I should put it back together and see if it's still working. And surprise surprise it still works. So here it is again, before I'll break it again re-implementing the way the user space talks to it.

BTW, it is still just barely enough to run safedisc 1.x copy-protection. Diff against wine-0.9.6

6. Ports: HP-UX, Solaris, AIX

(6 posts) Archive Link: "Wine on AIX 5.2 (PowerPC)"

Topics: Ports

People: Eric FriasGeoff Hart

There's no denying that Wine on Intel/AMD processors remains by far the most common use. However, there's a compelling reason for Wine to run on other platforms: you can recompile your Windows program using Winelib into a native application. If an ISV has a massive application written for Windows, it's attractive to be able to port the existing codebase to a different architecture. While the Unix playing field may be a lot smaller than in the past, there's still a significant userbase for many applications.

A question came up a few weeks ago regarding Wine on other platforms. Eric Frias mentioned SynaptiCAD has Wine running on HP-UX, though it hasn't been merged:

We actually managed to get HPUX (on PA-RISC) working reasonably well early last year. We didn't attempt porting a few of the parts I considered optional, like winedbg, oleaut32, and opengl. Still, it ran some pretty significant applications (i.e., mine :-) very well.

The assembly code generated for HPUX is a bit different from the other platforms, and all of the ifdefs in winebuild were getting pretty hard to follow. I'm hoping the recent changes to winebuild will make it easier to integrate, whenever I get around to updating... Until that happens, if anyone needs HPUX winelib, I'll be happy to send a tar of my working copy. It works on HPUX 11 and 11i, and maybe others.

The Sparc Solaris version of winelib we use works on at least Solaris 7, 8, and 9. It was working on Solaris 2.6 at one point, but we no longer have a machine that old to test on.

That response was actually prompted by an email from Geoff Hart about porting Wine to AIX:

Not sure if this is the correct mailing list, please redirect me if not. My goal is to port some Windows apps to AIX, so I decided to take as much Wine (winelib) as I could to help me. Initially I thought only a small portion would be suitable, but after a few weeks of work I have all the dlls/libs compiled (as simple AIX .so's) and because I'm quite naive about Wine internals, I went for wineserver also. My first question is: has anyone tried this before? I've been googling endlessly, and haven't found a single mention (unfortunately, "wine" and "aix" keeps trying to find French drinks). If anyone has, or anyone is interested in my (hacky) attempt, please email me directly (I try to keep up on this list, but I don't do very well). I wanted to avoid the "wine" loader, so I made a pseudo-main like:

Amazingly, after building one of our simpler Windows clients, I get:

That last line would repeat every 60 seconds or so.

So, if you have been kind enough to read this far, perhaps you also might share any ideas you have about what I have done wrong. I have traced through both the wineserver and winelib (ntdll, kernel, user, ...) code in the debugger but I haven't seen anything obvious (to my untrained eyes). I have been so bold as to even include my traces (the [PAUSE] in the client.trc is when I hit the breakpoint in the server, and start it tracing).

The problem might well be in my attempted ports of the pthread routines, the atomic operations, or some other assembly stuff.

There's also a lot of work by Alexandre to make Wine run on MacOS X, so Wine should be more portable than ever soon.

7. Running Winelib Apps

(3 posts) Archive Link: "Compiling test application (Notepad) with winelib - executeable segfaults"

Topics: Winelib

People: Richard WildVitaliy Margolen

Richard Wild had a question regarding the using Winelib:

I was trying to compile the test application (Notepad) with winelib to get a feel for how to use it. I followed the instructions in your docs, but ended up with a target file The instructions imply that I should end up with an executable called notepad2, since they tell me to run it.

If I run the .so file it segfaults, so I assume it really is a shared library and not just an executable with a funny name.

I want to understand what I've done wrong here, because if I can't get this right I certainly won't be able to port anything complicated. I'm sorry if this has been asked often before, but I couldn't find an easy way of searching the mailing list.

I am using WINE-0.9.4 built by Adam Schreiber for Slackware 10.2.

If that seems like an obvious question to Wine developers, then it just goes to show the documentation for Wine needs to be quite explicit in what it describes. Compared to Windows, Wine and Linux can be a strange new world for a developer. Vitaliy Margolen responded with the quick answer:

No winelib application is not a standalone as you would think. You need to run it in the same way as all the rest exe files: wine notepad2

8. MS Office on BSD

(1 post) Archive Link: "Microsoft Office on FreeBSD"

Topics: Ports

People: Tom WicklineMicrosoft

Tom Wickline announced something that might be of interest to BSD users:

I've put together a little Microsoft Office on BSD howto on the Wiki, If anyone here uses OpenBSD, NetBSD or DragonFlyBSD I would be interested to know if you can get Office 2000 to install and run with Wine out of the box or with my cheats. :D So others who read the howto in the future will know the status of there distro.

9. Debugging With Eclipse

(2 posts) Archive Link: "Winelib debugging with eclipse in fc4"

Topics: Debugging

People: Michael OstEric PouechMicrosoft

Michael Ost brought up using Eclipse a while ago and this week posted some info regarding using it with Win32/Wine development:

A while back I posted a question about how to get debugging working with Eclipse in fedora 4. I am having some success, so if anyone else out there is interested here's how it is set up.

In regedit:

In eclipse's Run/Debug dialog box:

The only weirdness so far is that sometimes (not always) the debugger suspends when a new thread is created. I just resume (F8) past that. And I am not sure what impact bypassing wine-preload's exec-shield workaround will have on me. More on that if I learn more.

But I gotta say that having a functioning IDE with integrated debugging on Linux is a major relief and, for me at least, a long time coming!

PS: I installed FC4, and then did yum update. eclipse is version 3.1.1 updated from the eclipse UI from the version that came with FC4.

Eric Pouech suggested more functionality could be achieved by changing that technique a bit:

You could (not tested) alternatively:

You would this way:

10. Winecfg & Audio

(22 posts) Archive Link: "winecfg: Problems with audio configuration"

Topics: Multimedia

People: Vitaliy MargolenRobert ReifJoseph GarvinMichael Jungcvs

There's been some large changes behind the scenes in winecfg with regard to configuring audio drivers. Robert Reif has done a lot of work in that area over the past few months. It led Vitaliy Margolen to ask:

I have noticed significant increase in crashes and lockups in winecfg's audio page. Could we do something about that before the next release?

This makes it hard for any first timer to configure Wine. Especially knowing that most people will have to change hardware acceleration to "emulation" and they will not be able to do so.

Robert gave a rundown of the current state of audio configuration a list of known issues:

I agree with you but can you be more specific?

There is a bug in arts itself which causes arts to crash. I believe this has been fixed in the latest arts libraries.

There can be a short hang in the esd driver if esd in not configured properly.

One person reported a computer lockup with OSS but that is probably a kernel driver bug.

Winecfg is now really using all compiled in audio drivers to do hardware probing of all available hardware. OSS with a real OSS kernel driver (not ALSA emulated OSS) is the only really stable setup now. All the sound drivers need to be looked at more closely now so they either work properly on a wide range of hardware or fail gracefully on misconfigured or marginal setups.

Contrary to popular belief, sound can work very well in Wine and even work better than on Windows but only with some hardware and with some versions of linux. In general, both Wine and the sound systems that it uses have a long way to go before they will work well for everyone out of the box. Even Windows has problems doing sound well for everyone out of the box.

That launched into a bunch of people bringing up all the problems they've had with audio. Apparently there's a lot of dainbramaged audio setups out there and winecfg can potentially trip over them now that it attempts to talk to the sound system. Joseph Garvin ran into one in particular that was ugly:

From a user's perspective, even if arts crashes, it shouldn't be taking winecfg down with it. Counting on users to have correct audio setups across distros sounds a bit utopian. Obviously we can't fix sound for the users, but we can at least show an error message saying what failed. Also, people who have arts installed but don't run it as their sound mixer still crash (happens under Ubuntu too).

I'm running Kubuntu on my desktop and clicking the Audio tab under cvs gives this:

Robert came up with a workaround:

The crash occurs in as shown above.

Can you try this patch:

It tries to catch the exception in the arts library. This is just a hack to work around a bug in the arts library.

Michael Jung mentioned it also solved his problem on his Debian Sarge system. There were some questions about Robert's hack and he explained:

The line ARTS_Init(); is what's crashing! This is the first call to the library. Clearly an arts library bug.

The point is that it is not crashing in winecfg or any wine code at all. Adding an exception handler to catch a crash in an external library may work but it's a workaround for a broken external library. The external library needs to be fixed.

11. Still Image Capture (STI)

(14 posts) Archive Link: "wine's setupapi.dll / newdev.dll ?"

Topics: Multimedia

People: Damjan JovanovicMike McCormackReactOSRob Shearman

Damjan Jovanovic wanted to know why Wine's setupapi.dll was so outdated:

I've been working on a still image implementation for Wine / ReactOS for a while now, and I've only recently realised how impossible it is in Wine at the moment...

Wine's SETUPAPI.DLL is not even in its infancy, it doesn't even let you enumerate non-serial-port devices, and doesn't load class-installers, so you can't even install a scanner's INF file. I see that ReactOS's implementation is better and it is under the right (LGPL) licence; are we planning on including it into Wine, and if so, when?

Wine's NEWDEV.DLL is pure stubs - so you can't even start installing the device INF file. ReactOS's latest SVN version of it is a little closer to what I need, but can we include GPL code in Wine? (I've asked the developers to relicense it under the LGPL for us, but they haven't gotten back to me yet).

So what should I do - submit my STI.DLL and STI_CI.DLL into Wine now, even though they won't be usable for a good while - or wait for Wine to mature?

And does anyone know any good documentation for writing COM out-of-process servers (that use ncalrpc transport and have some [local] methods)?

Thomas Weidenmueller mentioned that ReactOS' NEWDEV.DLL was under the LGPL and could thereby be used with Wine. That led Rob Shearman to ask what NEWDEV.DLL did. Damjan described it, " Called through rundll32.exe from umpnpmgr, it does all the user-interface aspects of device installation. All those screens you see in Windows, where you select a device category (eg. Mouse), then click "Next", then you see a list of manufacturers and their devices and that "Have disk" button, and then you select one and click "Next" and it carries on - all that is done by NEWDEV.DLL. "

Rob didn't think that sounded right for use with Wine. He suggested some how building the functionality into Winecfg.

Regarding general development, Mike McCormack suggested getting the code out there as soon as possible:

It's likely somebody will have some comments on your code or Alexandre will require you to change the way things are done before he accepts it into Wine.

With this in mind, you should submit what you have early to get feedback on it. You should also attempt to break it up into smaller seperate, independent parts where possible.

For example, if you've changed include/sti.h, you could submit those changes first, as they're low risk and should be applied without any trouble. Same for any other improvements to Wine that makes sense on their own.

Some people are working on a driver framework for Wine, so you might want to consult with them about the best way to share that framework.

Regardless of how Damjan proceeds, it appears a large merge from ReactOS' SETUPAPI.DLL will be required. Damjan volunteered to perform that merge along with NEWDEV.DLL.







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.