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 #305 For 10 Feb 

By Brian Vincent

Table Of Contents


This is the 305th issue of the Wine Weekly News publication. Its main goal is to charge batteries. 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 276 posts in 443K.

There were 92 different contributors. 56 posted more than once. 42 posted last week too.

The top posters of the week were:

1. News: Wine 0.9.7 & CXO for Linspire

(2 posts) Archive Link: "News"

Topics: News

People: Alexandre JulliardLinuxElectronsMicrosoftNews

Alexandre released Wine 0.9.7 last week. With releases being two weeks apart there's a little more granularity in the descriptions of new items. Alexandre noted the following significant changes:

Good stuff. Now go grab Wine from the GIT repository and compile it. All the cool kids are doing it.

Am I the only one who still wants to call them Lindows?

This week CrossOver Office for Linspire was released. The biggest thing here is the integration with the distribution. CXO 5.0 can be purchased directly through Linspire's CNR (click and run) distribution system. >From an article on LinuxElectrons:

"Businesses tell us they want to switch to the desktop Linux operating system to reduce total cost of ownership or improve security, but it's the thought of losing one or two software applications like Quickbooks or Microsoft Project that holds them back," said Kevin Carmony, CEO of Linspire, Inc. "CrossOver Office is genius because it removes that hesitation from the equation. Yes, you can still use Quicken or Microsoft software on your Linspire machine, but you don't have to overpay for a Windows operating system license to do it."

2. Eating Dogfood

(3 posts) Archive Link: "The Dogfood Challenge: use Wine to run your web browser, etc."

Topics: Testing

People: Dan KegelMicrosoftcvs

Dan Kegel thought some Wine developers should start eating their own dogfood:

Say, if we're expecting people to use Wine for real work, maybe we should start doing that ourselves.

Firefox-1.5 runs pretty well on Wine. How many Wine developers use it on Wine as their main web browser? Maybe we could raise that number from zero to somewhere around ten, and flush out a couple bugs.

Speaking of flushing out bugs, OpenOffice 1.1 was said to work well under wine a couple years ago (though I don't think I ever saw it do so myself). Sadly, although OpenOffice 1.1.5 seems to install fine under current wine, it crashes quickly on startup, so I guess we have a bit of work to do first. The extra payoff would be being able to use to run OpenOffice's automated test suite as an automated regression test for wine.

One complication in all this is having to teach yourself to not automatically blow away your ~/.wine directory when trying a new app!

He followed up on that later in the day with some benchmarks to prove Wine's performance isn't too far off native:

To see how reasonable it might be to use OOo 2.0.1 and Firefox 1.5 under Wine routinely, I benchmarked their startup time on a Fedora Core 5 test 2 system under four conditions: native vs. with wine from cvs, and with 416MB RAM vs. 96 MB RAM (by booting with mem=96M; this was to simulate running on one of those cheapo 128MB boxes that uses shared video RAM). This was on a zippy Compaq Presario 3000 Athlon 64 3000+. All apps were downloaded from and

Results for first run of app after booting (1st column is startup time):

So wine is 1.4 to 2.5 times slower at app startup generally, but when ram is really short, win32 openoffice starts up with wine 1.5 times *faster* than the native linux version! (Maybe because the Microsoft tools are better at avoiding I/O or relocations during loading?)

I then measured how long it took to start up the app the second time, when the cache was nice and hot:

The times are uniformly faster on the second run, but the patter holds, i.e. wine is 1.4-1.5 times slower than native generally, but win32 openoffice under wine is 1.5 times *faster* than the native version when starved for RAM.

There was concern FC5 might be throwing off the results, but Dan tried with Ubuntu 5.10 and found similar results.

3. MP3 Decoding

(8 posts) Archive Link: "MSACM: winemp3 codec crashes on seek, (no longer) reimplement with libmad?"

Topics: Multimedia

People: Alex Villacis LassoEric Pouech

Wine's MP3 codec for playing back MP3 audio seems to have some issues. Alex Villacis Lasso spent some time looking at it and wrote to wine-devel to see if anyone had any ideas for improving it:

I was trying to exercise the winemp3 builtin codec using a Visual Basic control that essentially implements the Windows Media Player look (MSDXM.OCX). After specifying native quartz.dll for this app, I tested a few AVIs with mp3-encoded soundtracks. What I can notice is that the sound has very annoying jitters, and in addition, it crashes on a seek. Some people have noticed the jitters too ( However, rather than trying to fix the wine fork of mpeglib, I was toying with the idea of reimplementing the codec as a libmad (GPL) wrapper. Are there any issues I should take into account before trying this?

Eric Pouech replied, " first of all, are we sure that the issue comes from the decoder itself (and not some wine wrapper around it) ? the second issue is that MAD is GPL... hence we cannot use it"

Alex investigated the decoder more closely, " I performed the following test: with the sample VB application, I modified the winemp3 code to write the input buffer (mp3) and the decoded output buffer (PCM) at the end of separate files. Then I played the mp3 samples file. This one plays correctly (rules out mangling of input buffers). The output file has quirks, but plays a little better than the output from the VB application (no delays), which suggest that there are some timing issues with the winemp3 code, or that the output duration, as reported by winemp3, is slightly incorrect."

Alex also pondered resyncing with the latest version of mpglib.

Eric thought the test didn't take into accoutn some other possibilities:

Or simply, that the sequence of:

  1. getting mp3 encoded data
  2. pushing them to the decoder for decoding
  3. pushing the decoded data to the speaker
runs slower than the expected pace...

which doesn't blame only step2, or the decoder itself. for example, putting the decoder in a separate thread would greatly improve, or using smaller packets in step 1.

Alex dug further:

I also ran tests with a different movie which uses the Indeo codecs (native) for decoding. This one runs smoothly (with audio AND video). In my opinion, this is additional evidence that the winemp3 codec is at fault (especially since my sample movie uses a not-installed DivX video codec which therefore does not consume any CPU, as it is running in audio-only mode). The native Indeo codec also does not crash on seek.

On a side note, is there anybody in the list with experience with GStreamer programming? The base GStreamer framework is LGPL, so it *might* be legally possible to write a GStreamer wrapper for wine. Of course, there might be an architecture difference that makes this impossible, so any feedback will be appreciated.

Followed by:

Some more tests. I downloaded the latest version of mpglib, and compared it against the wine fork. Aside from extra spaces and an one-time-only initialization in the wine code, the current mpglib code is almost identical to the wine fork. However, the standalone mpglib decodes the extracted samples correctly. This means that there is something about the Wine environment that disturbs mpglib enough so that decoding no longer works correctly. I also noticed that mpglib uses malloc() and free() from glibc even inside the wine copy (one malloc()/free() pair per sample block to be decoded). Could this be causing some interference (especially since the wine architecture decodes in a separate thread)? Maybe it is worth it to use HeapAlloc()/HeapFree() instead.

Eric didn't think HeapAlloc was necessary. That was the end of the discussion, but it seems like Alex is still looking into it.

4. Demangling Symbols

(9 posts) Archive Link: "VC++ demangling tool"

Topics: Utilities

People: Michael StefaniucEric Pouech

Automatically demangling symbols generated by Visual C++ is a handy feature. Michael Stefaniuc came up with a new, little Winelib app to do it:

winedump has a VC++ symbol demangling function but that is bitrotting as it is a copy of the msvcrt.__unDname . As i wanted to use the newer msvcrt.__unDname funtion i have written a quick and dirty program that is basicaly only a wrapper around UnDecorateSymbolName(). Most importent feature is that it runs on the command line. I'm not expecting it to go into Wine but others might find it useful. After applying the patch configure needs to be regenerated.

Eric Pouech pointed out there's an MS tool that does exactly that:

actually, there's a tool in the MS SDK called undname that does exactly this... it has also a couple of other options (like demangling all symbols listed in a text file)...

but what should be done is to port back the code from msvcrt into winedump

The last thought prompted Michael to ask, " I'm wondering, why can't winedump import msvcrt and call what it needs, instead of duplicating code?"

Eric gave two reasons:

Then a discussion ensued about whether winedump should become a Winelib app. Almost everyone was opposed to it, but there seemed to be a strong argument for being able to utilize Wine's msvcrt.dll rather than duplicating code.

5. Winelib & Easy Distribution

(11 posts) Archive Link: "Somewhat disappointing experiences with Winelib and WTL"

Topics: Winelib

People: Claus FischerRob ShearmanDmitry TimoshkovMike HearnBoaz Harrosh

Claus Fischer looked into using Winelib and WTL for simple application development and deployment. He sent a rather long summary of what he discovered:

Over the last few days, I have been trying to find out whether the combination of WTL and Winelib could be a promising inter-platform GUI solution.

While I have made some progress and got some new knowledge, I believe I have now come to a dead end where I'll have to give up that attempt.

In case you are interested, here's my summary report.

It might be useful to others.

The Goal:

WTL on Windows gives me:

The goal is to combine WTL/ATL (no COM) with Winelib to create a Linux-application with the same look and feel and roughly the same qualities: no DLL's, shared libraries, C++ ABI hassles, etc. Just one binary linked to libc.


ATL 3.0 (from my MSVC 6 compiler) and WTL 7.5 (from sourceforge) can be made to work. Issues are:

Basically, ATL+WTL can reach a state where they compile with GCC 3 and the changes are still mostly cosmetic. Some of the changes might even be incorporated in the official WTL, now that it's free.

I have read the mails of Boaz Harrosh' previous changes; apparently he has had to invest much more work because of COM.

With the modified ATL/WTL, I was able to compile the wizard-created sample SDI application on Linux.

2. Winelib "as is"

After some digging through the Web, I've been able to link the sample SDI application against Winelib.

It took somewhat longer than it should have due to

  1. WTL's habit of just ATLASSERT()ing things and
  2. the rather elaborate work of finding those places with wine-dbg and/or ATLTRACE()s plus WINEDEBUG=+relay.

Since I'm not familiar with the Wine debugger, it would have been very helpful to be able to use gdb on the resulting executable. However, gdb reported that it didn't know the file format.

Wishlist for Wine:

All in all a reasonably successful endeavour, and the application runs stable and looks fine except for the font (that probably can be configured better).

BUT: ... BIG SHOCK: That's not a single ELF executable, it's a weird mixture of PE and ELF and a .so file and a wrapper program that apparently starts wine in the background ...

That doesn't fulfill my goals of building a native Linux exe with no dependencies except libc.

It's also quite slow when loading.

3. Winelib statically linked

Apparently Wine has made a decision a few years ago: that support for native Windows apps with all the infrastructure they need (Wine server, registry, resources, multithreading, etc.) is more important than support for porting applications to native Linux apps.

That decision is obviously correct, given the large number of Windows applications that are only available as binaries and require much infrastructure.

I'm aware of that, but I've still decided to give my dream of a native Linux app a try.

I tried the following method:

  1. Get and compile Wine 0.9.7
  2. Add rules to Makedll.rules to pack the objects into .a libraries
  3. Attempt to link my program's objects against those static libs
  4. Make changes and corrections and repeat

I first made a reduced WTL application that does not use a resource file. I don't know if this was a good decision.

The following changes were necessary to Wine:

This is where the heavy trouble started:

What eventually caused me to stop is:

This is where I stopped.

I don't know whether I'm "so close" or miles away, but my random code editing seemed to get out of hand.

4. What is needed

What would be needed to support static linking against Winelib (if that's decided to be a supportworthy goal):

What I specifically don't need/want through Winelib:

Also, if anyone is interested in hosting patches to ATL/WTL or even just looking at them, I'll gladly provide them.

Rob Shearman pointed out the wineserver is a necessary component:

You really don't want to try without wineserver support. Nearly everything depends on at least one feature that the wineserver provides. If you try to make your own version of wineserver that is somehow statically linked into the application you will have to completely change how it works and maintain that version on your own.

You're doing a noble thing in trying to get your Winelib application easy to deploy, but I think you're going about it the wrong way.

For maintainability, take a look at using the WINEPREFIX environment variable and use dynamic libraries. That way you can deploy upgrades of your application in a small installer, whilst not needing to update the Wine libraries. If you need a bug fix in a Wine library, then you can just update the one dynamic library that has changed. If the startup speed isn't good enough for you, you can use oprofile (or some other profiling framework) to work out which functions are taking up time. We would welcome any fixes to improve the startup speed. Optionally, you could comment out functions do things that you don't need.

Claus explained a bit more about the application and ho he'd like to deploy it:

But with WTL, it's possible to build a reasonable sophisticated application that depends only on DLLs that are already on the system.

My biggest WTL application so far, a project for the Austrian Mountain Rescue Service, has roughly 100.000 lines of code (sloccount). You can find a description on (a bit outdated though).

When the first phase was finished, the program would still run under Windows 98 SE upwards. It now depends on the following DLL's: VERSION, WS2_32, KERNEL32, USER32, GDI32, COMDLG32, ADVAPI32, SHELL32, OLE32, WININET, COMCTL32

On any reasonable PC with internet access (it's a networked application talking to several redundant data servers), you will find those.

Therefore, Installation is as easy as copying the EXE and starting.

That is a requirement, since the Montain Rescue Service is a volunteer organization with members from all kinds of social background, work environment, and Laptop infrastructure.

For this reason, having WTL+Winelib for Linux would have been just too nice to think of :-)

That prompted Dmitry Timoshkov to point out the underlying facilities to support those DLL's were non-trivial, " You seem to underestimate what the dependencies above mean for the running Windows system. You depend on the whole kernel + GUI subsystems, including registry and everything else. That's true for Wine as well, just in the case of Wine you see all the dependencies, not just the imports section of your exe file."

Claus felt the goals of Winelib had fallen by the wayside, which is partially true, " However, through all that progress supporting native Windows applications (which must be the main goal, of course), the "portable Windows GUI" idea has naturally fallen by the wayside somewhat, and the usefulness of Winelib as an application porting toolkit is therefore questionable."

Mike Hearn felt Wine wasn't the tool for the job in question:

Win32 in general could never be described as "promising" no matter what libraries you wrap it with. Wine is best used for porting and compatibility rather than new app development. Libraries like GTK or Qt are far better

Your actual goal is described here - you want a program that is free of dependency hell. A noble goal indeed, but the right way to do this is to investigate things like autopackage, ELF statifier, and so on. And also to accept that a program with no dependencies is perhaps not so useful after all. For instance, you can probably find GTK+ 2.2 or higher on everybodies system these days.







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.