Wine Traffic Brian Vincent

This is the 309th issue of the Wine Weekly News publication. Its main goal is to become long overdue for a Spring cleaning. 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 Slashdot News

Last Wednesday, Alexandre released Wine 0.9.10. It followed less than 2 weeks on the heels of 0.9.9. He noted the following changes:

  • Improved ESD audio driver.
  • More Web browser improvements in mshtml and wininet.
  • Direct3D fixes and preparation for ddraw code migration.
  • Explorer process now managing the desktop window.

As usual, you can find the latest binaries on our download page. Or, grab the source and start compiling. It's fun for the whole family.

Last week we missed reporting on a story from Slashdot. It seems a gamer using World of Warcraft under Wine was banned. Although Wine was part of the news story, it appears Wine wasn't responsible for the player getting banned: he had keyboard macros set up and got banned for botting.

Packaging

Wine's Red Hat and Fedora packages haven't been updated since Wine-0.9.2 a few months ago. There were some grumblings on wine-devel this week that something should be done about it. Neal Gompa asked, What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs...

Normally that many exclamation points would turn into a flamefest on a mailing list, but several people responded with solutions. Michel Ludwig provided the first one:

Fedora Wine packages are in Fedora Extras:

And even a "yum install wine" should do it (as root of course :-)).

Well, that's pretty simple. Andreas Bierfert noted that Wine made it into the x86_64 tree of Fedora Extras as well and a yum install wine should work.

Eddy Nigg of StartCom Linux mentioned they had Wine in RPM packages that should be compatible:

We just compiled the latest wine rpm for our upcoming MultiMedia Edition....no problems at all...We made only minor adjustments, to reflect the fact, that it's a StartCom build and not Fedora....

The files can be used of course by any compatible OS:

[ed. note: list expanded from original email to be more download friendly]

That's a lot more packages than a typical Wine installation; it almost looks like something Debian would come up with.

Microsoft Windows Microsoft

As we get closer to the next Windows release, there's bound to be some questions regarding how it affects Wine. Well, the short answer is, it won't for quite some time. It will be quite a few years before software specifically targets Vista, although it's likely Microsoft Office will lead the way. It's only been within the last year or so we've seen Windows 98 begin to be unsupported. So it'll be a while before we have to worry Vista (especially now that the release has been pushed out until 2007.)

Mike Hearn shared some info this week about some of the API changes within Vista:

Potentially this is old news, but via Raymond Chen we learn of this page:

Which talks about Vistas application compatibility. Interesting points that stand out:

  • They are dropping WinHelp and CHM support. You'll have to install it from their website for it to work (my first thought: wtf?)
  • IsBadReadPtr/IsBadWritePtr are now "banned". I wonder what that means. Presumably it just means they don't use them internally for the APIs anymore.
  • Windows will now silently fail to modify certain protected system files even if you're the administrator (basically the STATUS_ACCESS_DENIED error is suppressed to stop installers tripping up).
  • They dropped D3D RM. Not many apps use this but I think at least my fathers sailing game does.

So there we have it - this appears to be the first release in which they simply started dropping APIs.

That led Scott Ritchie to remark, And, therefore, the first time for which we can categorically state that Wine will be more compatible with Windows applications than Windows itself.

One item I found rather amusing is the User Account Control. Vista will now have separate administrator and user accounts with almost all programs running as a regular user. This isn't much different than *nix where root privileges are separate from user privileges. While NT has had this for years, it hasn't been something home users have really dealt with. Congratulations Microsoft, you've once again reimplemented a concept thirty years old.

Fixes cvs

Consider the following line of code:

    ListBox_SetItemData(hlbox, idx, pTxt);

Though taken completely out of context, it appears we just have a some ListBox control call going on. Nothing fancy at all. Internally, Wine uses the Win32 API as much as possible until you get down into the low-level stuff and this just looks similar to any other Win32 call.

However, behind the scenes ListBox_SetItemData() is simply a macro that lives in include/windowsx.h. It's actually defined as:

    #define ListBox_SetItemData(hwndCtl, index, data) ((int)SendMessage((hwndCtl), LB_SETITEMDATA, (WPARAM)(int)(index), (LPARAM)(DWORD)(data)))

Not so pretty, eh? It also generates GCC warnings due to the casts, which is generally considered a bad thing. Mike McCormack sent a series of patches last week to replace code like that. It sparked some controversy whether his patches were actually better or not. Rob Shearman fired the first shot:

Why don't we fix the macros as suggested by Francois, rather than preventing its use? It seems like a big waste of time to have submitted all of the patches to the files using windowsx.h when fixing the macros is necessary for Winelib anyway.

Mike explained his reasoning:

No, it's not a waste of time. Having warning free Wine source code is far more important than any warnings that might be in 3rd party winelib code.

Francois' solution is still not perfect, as it requires use of a non-portable C construct.

Rob didn't think that was an issue and reminded everyone of Francois' original idea:

We're trying to work around GCC warnings that probably aren't generated using any other compiler so using non-portable C constructs is perfectly fine. Here is Francois' solution again:

    #ifndef WINE_CAST
    # if __GNUC__
    #   define WINE_CAST(ctype, val) ({ctype r=(ctype)(val);r;})
    # else
    #   define WINE_CAST(ctype, val) ((ctype)(val))
    # endif
    #endif

    #define Header_SetImageList(hwnd,himl) (HIMAGELIST)SNDMSGA((hwnd),HDM_SETIMAGELIST,0,(LPARAM)himl) WINE_CAST(HIMAGELIST, SNDMSGA((hwnd),HDM_SETIMAGELIST,0,(LPARAM)himl))

It seemed to be ignored by both you and Alexandre last time it was sent, and all of your patches applied anyway despite objections from several developers.

Alexandre then explained why he applied the patches:

I think these windowsx macros are confusing things more than helping, especially since they don't look like macros. It's better to have explicit SendMessage calls than some pseudo function calls, it makes much more obvious what's going on, especially for people who try to debug the code without being very familiar with the Windows API. The fact that getting rid of the macros also avoids the warnings is just icing on the cake.

An example was cited where the new code looked pretty messy compared to the old stuff and it was questioned whether it was really better. Alexandre felt it was:

the code makes it obvious that we are sending a message here, not calling a function (or worse, a macro disguised as a function). In many cases that's important information, for instance when you try to match a message trace with the code. The casts are ugly but they are present in the macro too, so it isn't any more typesafe, it just looks like it is.

The changes stayed in.

Someone wrote in suggesting Wine should have a way to disable networking within applications:

I think it would be very useful to disallow an application started with wine i to connect to the network/internet by an options flag.

That's a valid question - a lot of apps like to "phone home" and that's rather annoying. Currently Wine just inherits and utilizes the underlying networking available. Along those lines, a solution was presented using iptables:

I don't know how much of wine's source would need to be changed to disallow all network commands, but I know that this kind of thing is possible using iptables (particularly with the owner extension).

If you create a new user id (which will be the one you use to start the application, using su or sudo), something like 'nonet', then run the following:

    iptables -I OUTPUT -m owner --uid-owner nonet -j REJECT --reject-with imcp-net-unreachable

or something like that (I haven't tested it), it will block the 'nonet' user and any applications started as it from sending network packets.
Microsoft

Steven Edwards let everyone know about a large chunk of Windows code that's been let loose:

It seems Microsoft has MS-FOSSed Mech Commander 2 under a shared source license

According to the appdb it does not run so maybe having the source could better help us find out what we are missing.

It's not every day the source code to a large Windows program becomes available, especially one owned by Microsoft. It could be a fun project to get it running under Wine.

Olaf Leidinger mentioned the source to another game has been available for a while:

The source of Civilization "Call to Power 2" was also released some years ago. Have a look at