Wine Traffic #264 For 4 Mar 2005

By Brian Vincent

Table Of Contents


This is the 264th issue of the Wine Weekly News publication. Its main goal is to edit, rewrite, edit, and rewrite. 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 294 posts in 1737K.

There were 86 different contributors. 53 posted more than once. 40 posted last week too.

The top posters of the week were:

1. News: WGA Update

26 Feb 2005 - 4 Mar 2005 (2 posts) Archive Link: "News"

Topics: News

People: ZDNetspidertools.comMicrosoftSlashdotNews

Shortly after last week's WWN, Microsoft decided to comment on the Wine check added to the WGA software. Keep in mind, this check will be necessary for anyone downloading applications from ( in the future. ZDNet (,39020330,39189180,00.htm) carried the story and included this quote from a Microsoft spokesperson:

"As the most popular third-party translation technology in use, Wine was the first emulator to be specifically tested for via WGA," said the spokesperson. "Microsoft does not knowingly provide copyrighted Microsoft Windows OS files to users of third-party emulators or cross-platform API translation technologies such as Wine."

The spokesperson said users who are not running Windows XP or Windows 2000 natively can still download updates for Microsoft Office from the Office Update Web site.

The story was picked up almost immediately by Linux Today ( and Slashdot ( .

Feel the love.

Lately it seems pundits like to attack Linux on the grounds that it really isn't cost effective. Now, any sys admin can tell you that's not true - just the time and effort involved in managing licenses can require a dedicated person on staff in a large business. However, the open source community doesn't seem to have much empirical data to back up their claims. I thought it was interesting this week to see something come out discussing a Linux + LTSP + Win4Lin installation ( :

The goal of the project was to create an fully functional lab for about $200 a computer which had to factor in the cost of a server, software and a GB switch. A Windows based lab with XP was priced at $1748.30 per computer (includes server, software and switch) while the actual Linux solution cost only $216.30 per workstation. The cost savings was substantial and allowed the district to view the project as a long term solution based on price.

That's pretty significant! The article explains the installation encompassed 125 workstations served by 3 LTSP servers. Rather than use Wine, the school system decided to use Win4Lin for Windows emulation. They already owned Windows licenses, so that wasn't a concern. In addition, it sounds like they had some older CD-ROM media they needed to access. It sounds like the cost savings would have been even greater if they used Wine since the Win4Lin licenses wouldn't need to be purchased. (I'm sure it was considered, but for whatever reason wouldn't work for them.) Extrapolating the cost for the 125 workstations and 3 servers, the grand total comes to $27,686 - a modest amount for any IT project of this size.

2. RichEdit Work

28 Feb 2005 - 3 Mar 2005 (2 posts) Archive Link: "riched20 and test app"

Topics: Status Updates

People: Krzysztof FoltmanMike McCormack

Krzysztof Foltman began submitting the new RichEdit work. His first patch described a bit of where he was headed:

This is an attempt at starting a RichEdit 2.0 clone, plus a test app for it (which I, for some reason, decided to call Wine WordPad).

It lacks most essential functionality, and source formatting is not exactly standard, but it has enough functionality to make a couple of Wine developers convince me to release it now. Or weeks ago.

The test app uses the Mike McCormack's test snippet to fill the control with some fancy formatted text.

Hope the patch is OK. Adding new DLL's and EXE's isn't an easy process.

Wordpad on Windows is a wrapper around the RichEdit control, so it's logical Wine's app is named similarly. Mike McCormack looked over the patch and had some comments:

Cool. Looks like you've done alot of good work.

I like that you've used lots of small functions, rather than monolithic 200 line globs. I like the asserts too.

OK, now some suggestions:

3. Wine Status

4 Mar 2005 (1 post) Archive Link: "Wine Status"

Topics: Status Updates

People: Tom WicklineJasonReactOSNewsEric KohlRobert ReifJeremy WhiteWineHQSteven Edwards

I've neglected to update the news on WineHQ to mention we've updated status of key areas of Wine ( . Tom Wickline went through each area a few weeks ago. I asked Tom if he'd give a status update on the status updates so I could get a feel for the changes. There's a lot of things that go on with Wine development that don't get included in the Wine Weekly News. Some of the best patches are so well done they don't generate any discussion. Tom put together a really nice summary of the state of Wine development and some of changes we've seen recently:

Wine's fundamental architecture

The DOS drive devices stick out as a huge change, that was about 8 months ago. Here is Eric's first mail on the subject. (
Window management
AJ has done a huge amount of work here :-)
DLL separation
Eric and AJ keep chugging along at this..
Unicode support
There has been hundereds of patches to convert to unicode support.
Wine Conformance Test Suite
Francois tells me the infrastructure for the Conforance test is now finished.
Wine IDL compiler (widl)
Huw is on patch #38 (
Steven Edwards sent a patch to sync with ReactOS, the work was done by Eric Kohl. (

Dll's Status

advapi32.dll & rsaenh.dll (
Eric has sent alot of dbghelp fixes
This little dll goes a long way toward getting html help working in apps. (
The color management DLL is about 25% complete now. The fun projects status needs to be updated.
Mike and Aric has done alot of work here...
As of today Robert & Mike are on patch #76 of ole work. In the end this will help installshield work better and get us away from the MS dcom9x.exe dependancy.
Huw implimented stdole32.tlb :-) one huge step toward not needing any part of dcom9x.exe....

DirectX Status

Here is Jasons last d3d9 patch, #22, he is waiting on Oliver to sync his changes and then he can move forward. (
Was part of the d3d9 work from Jason. Raphael has done alot of work here as well: (
DirectMusic (as a group)
Raphael & Christian have sent a couple nice patches in the last couple months to bump the status on a couple of DirectMusic dll's
What can I say; Robert Reif has sent hundreds of DirectSound patches alone! Jeremy White is trying to track down the mmtimer bug and has sent some patches as well.
Christian has sent over 30 quartz.dll patches in the past six months.

Multimedia Status

Eric has done alot of unicode work on the multimedia codecs (
Here is the big patch: (
I sent the patch to sync to latest OpenGL specifications. (
Raphael,sent his patch to impliment partial PBuffer support for wgl and minimal pixel format support for wgl (

Tom also mentioned that we're seeing a lot of development right now. Some new folks have recently started working on different areas of Wine. We've also seen a large increase in the number of patches coming in each month.

4. Running Visual C++ With Wine

2 Mar 2005 - 3 Mar 2005 (7 posts) Archive Link: "Visual C++ 6.0 as a Winelib IDE?"

People: Ira KrakowDimitrie PaunBoaz HarroshDimi Paun

Ira Krakow reported on using Visual C++ with CrossOver Office:

I have Visual C++ 6.0 running under Crossover Office 4.1, which of course means it's running under Wine. For one of the examples in the Wine/Winelib book, I decided to take the code produced by the VC++ Win32 "Hello World" wizard and see how to port it to Wine.

Turns out, it's almost trivial. Create an empty directory, copy the *.c, *.rc, *.h, and *.ico files to it. VC++ produces tons of other files, but they're either used to maintain the Visual Studio environment, or are intermediate compilation files that aren't needed. Then run:

The Makefile that Winemaker generates _almost_ works. You need to delete the references to the mfc library and mfc.dll. After doing that, running make generates the .so file. Wine runs it flawlessly.

I got to thinking - can I convert the code from the MFC application as easily? Seems like it's doable, because the generated code runs in VC++/Crossover Office 4.1. I tried the same steps as before, with Winemaker, but I couldn't figure out what Makefile modifications were needed.

All of this got me to thinking - could Wine running Visual C++ be a viable IDE for porting? Maybe just linking VC++ with the Winelib libraries would do it. Maybe after tweaking Winemaker and publishing a HOWTO we could show that this is a viable path? It's certainly easier than for Visual Studio developers and could help attract them to Wine.

Another benefit - we could use the Visual C++ sample programs as tests for Wine. The programs might exercise areas that haven't been tested thoroughly.

Dimi Paun answered the last few questions succinctly, " This can't be done, we don't have VC++ sources. And besides, you don't get any additional benefits as compared to just running the native PE."

Rather than use winemaker, Boaz Harrosh suggested:

There are 2 easier ways that I know of to do this.

  1. Use dev-c++ from ( . It will Just open your DSP file and make a very good, very simple MinGW makefile for you. It will add all your -D and -I and all this nightmare in big projects. Both the result makefile and dev-c++ itself can be used with wine. It has a native Linux port has well. One thing to try is debugging. It uses gdb for windows. Does gdb for windows runs under wine??
  2. Grab the DSW2MAKE util from MinGW. Written in Perl. The output makefile is very good for Winelib. Also keeps your -D(s), -I(s), and -l(s) and tries to convert other switchs as well. Better for very big projects.

Ira described a bit about using the debugger and a few of the problems he ran into with it.

5. Tests for cabinet.dll

27 Feb 2005 - 1 Mar 2005 (4 posts) Archive Link: "Wine cabinet.dll FDI Conformace Test Patch"

Topics: Testing

People: Rizwan Kassimcvs

Rizwan Kassim submitted an almost 4000 line patch to wine-devel to get some feedback:

Aleksandr Liber and I have put together a set of tests for cabinet.dll. Before we submit them to wine-patches, can anyone offer any critiques/input? We plan to submit in a day or two.

We're 4th+ year undergraduate students at the UCLA Computer Science program. We're among a group of students doing conformance tests as part of a software engineering course - more info can be found at

Any advice you can offer will be greatly appreciated!

Wine cabinet.dll FDI Conformace Test Patch (gzipped)

Raw files available at :

This patch adds tests for the cabinet dll, specifically testing the functions FDICreate, FDIDestroy, FDICopy and FDIIsCabinet. As the FCI functions are still marked TODO in wine, they haven't been tested.

The package is self containing, allowing additional cabinet features to be tested by preparing other cabinets in the same manner that ours were. A patch of -p1 will be needed.


Andi Mohr pointed out some minor issues with it. The patch was modified and submitted to wine-patches a few days later. We haven't mentioned Wine's testing infrastructure in a while. A few years ago it was a hot development topic as it was getting off the ground. These days it's quite stable and tests are a regular part of the development process.

6. Google's Picasa2

27 Feb 2005 - 28 Feb 2005 (2 posts) Archive Link: "[SOLVED] Re: Picasa2- works great, one font issue"

Topics: Fixes

People: Matthew MastracciTroy Rollo

Apparently Google's new Picasa ( image software works with Wine. Matthew Mastracci reported that a recent patch from Tanabe Hiroshi fixed some problems with it. He added:

Here's some screenshots from the program while running:

Note that clicking the "email" button in Picasa will crash it - probably the MAPI stubs that cause it:

Troy Rollo mentioned the same patch fixed other issues, " Many DirectX games also had font problems fixed by that patch. In fact any application where the fonts looked like random noise is likely to have been fixed to that extent by that patch. "

7. Dragon Naturally Speaking Working

2 Mar 2005 - 3 Mar 2005 (3 posts) Archive Link: "Dragon Naturally Speaking - working."

Topics: Multimedia

People: AnonymousMike Hearn

Someone figured out how to get Dragon Naturally Speaking working with Wine. They described the process:

Good news and what looks like a first.

Dragon Naturally Speaking 4 working under Wine.

  1. Install Dragon from CD no major issues.
  2. copy missing dll's
  3. ran up Dragon , enter user name , setup sticks at setting mike level but exits cleanly.
  4. #wine gentrain.exe picks up user name, dictated training text. It saves the vocab/voix profiles the drops out with 3 repeat errors but the profile is safe
  5. #wine natspeak.exe

Can now dictate in stand-alone mode as in windoze.

I now need some help with the guts of Wine to see if I can capture the keystrokes output by Dragon and pipe it to another Linux thread.

Any suggestions on that?

Mike Hearn suggested, " Look at the XTest or Xevie X protocol extensions, they might be useful "

8. World of Warcraft (con'td) & Sound

24 Feb 2005 - 3 Mar 2005 (7 posts) Archive Link: "World of Warcraft - crash in game"

Topics: Multimedia

People: Alex WoodsFrancois GougetPaul van Schayck

After last weeks news about getting World of Warcraft to run (see WWN #263 ( ), Alex Woods ran into another problem:

World of Warcraft is working beautifully now apart from a crash that occurs seemingly randomly. The application is catching the crash, and giving a message like this:

A few few days later, Alex stumbled on what seemed to be the source of the problem:

Whilst playing around trying to get some kind of lead, the sound cut out on me whilst playing the game. I decided to keep going, and the game played for a surprisingly long time. The next day I booted the game with wine's sound drivers disabled and played for about 10 hours total without a crash (for purely stress-test reasons you understand ;)). I've had a chance to give it a go with the now and that also seems stable, so I guess the problem is in which I had been using.

I haven't had a chance to try to get some debug logs just for the sound yet, but when I get the time I will.

Paul van Schayck also reported sound problems of a similar nature. Francois Gouget explained some of the problems with sound in Wine and how to go about troubleshooting issues:

Sound depends a lot on the sound card. Some sound cards support only specific sampling rates while others are more accomodating. And that's just one issue, at least on the wineoss side there are a lot of other issues such as mmap support, full duplex support and DSP_GETOSPACE support that vary from one sound card to the next (and to some extent from one Alsa configuration / OSS emulation version to the next) and which all cause trouble.


And Wine is way too sensible to these issues, even more so if the application uses DirectSound. Part of this is because the Windows API is painful to emulate, but part of it is lack of debugging of basic sound. Unfortunately, debugging supposes one has a sound configuration that does not work which makes it even trickier.

What this means is that each Wine developer who has sound problems can essentially only count on himself to debug them. To do so I would recommend first checking that winmm works fine:

and if the above works, do:

And if the winmm tests worked fine, then do the DirectSound tests:

already you may have to manually edit the Wine configuration file to set HardwareAcceleration = Emulation. That's an heresy, it should be automatic. Anyway once you get the above test going, do:

I know for a fact that many Wine users are having problems with basic not-low-latency stereo sound and unfortunately I have not seen any progress on this in the past couple of years (i.e. there are still about has many users having problems now as two years ago).








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.