World Wine News
by Brian Vincent
- News: CrossOver Update, Mac News
- Changes to Fedora Packages
- ClamAV Integration
- Safedisc RPM
- Win64 / 64-bit Winelib
- DWARF2 Testing Needed
- Indenting Traces
- GUID List
This is the 318th issue of the Wine Weekly News publication. Its main goal is to look for plane tickets for WineConf 06. 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
This week, 555 posts consumed 1003 K. There were 121 different contributors. 70 (57%) posted more than once. 43 (35%) posted last week too.
The top 5 posters of the week were:
|News: CrossOver Update, Mac News||Archive|
CodeWeavers released an update for CrossOver Office (CXO) this week bringing it up to version 5.0.3. While this is just a bugfix release for CrossOver Professional, it brings the server edition product up to the 5.0 level for the first time. For more info, check out the announcement . Fixes include better support for iTunes and changes to work with Fedora Core 5. This is the first update in about 6 months and perhaps the last one we'll see in the 5.x line.
Appearing in the ZDNet family of publications were a series of articles discussing upcoming CXO support on Macs. From CNET.c.uk, Wine lets Windows run on a Mac nicely summarizes the direction CodeWeavers is taking CXO:
While many Windows programs may work with the Mac version of CrossOver Office, CodeWeavers will support only a handful. These are likely to include Microsoft Project, Microsoft Outlook and the Windows-only game Half-Life 2, White said.
|Changes to Fedora Packages||Archive|
A few weeks ago (WWN #316 ) we mentioned Andreas Bierfert had taken over building packages for Fedora. He wrote in this week to let everyone know he'd made some changes to the way the packages are configured:
some of you might have noticed that building 0.9.16 for Fedora Extras took me more time than the releases before. This was because of the discussions from a couple of weeks ago on this list. As a result I did spend some time on the mentioned issues and came across an easy solution:
If you install wine form the Fedora Extras repository via yum install wine nearly everything that would be in a monolithic package is going to be installed. The wine package now is a meta-package containing requires for the various subpackages. So now 'normal' users who do a yum install wine will get everything they need and experts who know what they are doing can go and install only the parts they want. I hope that this solution now leads to fewer 'false positives' on bug reports and for better user integration and satisfies some of the things you, the wine folks, brought up.
Thanks for the input on this matter. I hope that this is only the first step towards a good relationship between wine and the fedora packages for wine and that emails like the ones from a couple of weeks back won't happen again...
So for the announcement:
wine 0.9.16 for Fedora Extras 3,4,5,devel is built and should be pushed to the mirrors in a couple of hours.
Summer of Code 2006
Christoph Probst has started in on his Summer of Code project and asked for some assistance regarding integrating with ClamAV :
I'm one of the Google Summer of Code students and I'm working on the ClamAV integration in wine. Today I was discussing an issue with my mentor and he suggested to post it here.
Currently I'm working on a scan-after-write functionality: Whenever a file was changed the virus scanner checks the file.
My plan is to hook in NtWriteFile() (dlls/ntdll/file.c), because whenever a windows program writes to a file this function is called. Within this function the file is accessed using its unix_handle.
The problem is that I need to know the unix filename for clamAV to access the file, but I see no proper way or function to get it as long as I just know the unix_handle or fd.
Possible solutions so far:
But maybe I just missed an even better approach. What would you recommend to do? Any comment is appreciated.
Alexandre replied first, You can't do that in general. In Unix a file can have multiple names, or even none at all, there's simply no way to get a filename from a handle. On Linux you can use /proc/self/fd but that's not very portable.
Chris thought his third option might be the way to go then:
So what do you think about the solution that the wineserver stores the filename in the file object when the object is created?
Just like wine_server_handle_to_fd() there would be a wine_server_handle_to_filename() that returns the filename.
Any objections to this?
Alexandre still didn't think that would work, Like I said, there's no guarantee that the file even has a name, or that it is accessible under the name that was used to open it, so we can't provide such an API.
Eric Pouech then wondered if it would be easier to modify ClamAV to take a file descriptor as input. Kari Hurtta pointed out that ClamAV already can take a stream of data. Kuba Ober was concerned that would kill performance, especially since there's a lot of cases where scanning isn't completely necessary. Chris decided to go back and take a closer look at the functionality already built into ClamAV.
The Safedisc saga continues. Ivan Leo Puoti posted an RPM a few weeks ago for anyone wishing to play with copy protected games using Wine:
Safedisc has now been working on wine for almost a year, but it'll still take some time before we get the code into winehq, so I've decided to build an RPM of wine with safedisc 1 support so users can play around with it, you can download it from
Safedisc 2 and above are not supported. This is based on wine 0.9.16, however it isn't an official winehq release, and is provided on an as is basis. To run a safedisc protected game, you must run winecfg and set the drive type of your cdrom drive to "cdrom" in the drives tab. Yes, this sounds dumb, but it has to be done. Then run the game normally, and as long as you have an original CD (Ok, copies can work too but that's Macrovision's fault) in the drive, the game will start.
Mike Hearn asked for the necessary patches to be added to the wiki for reference. In related news, Vitaliy Margolen submitted a patch that adds some of the important infrastructure for later ntoskrnl patches.
|Win64 / 64-bit Winelib||Archive|
Good ol' 64-bit support. Windows supports it now and there's been some rumblings for a while about Wine needing to support 64-bit Windows binaries. Ge van Geldorp dropped a series of patches last week fixing up a lot of issues with Wine. At the end of the patches he explained what was now possible:
With the Win64 patches I just submitted to wine-patches, I'm able to successfully build Win64-enabled Wine and execute the following 64-bit winelib (winelib64? wine64lib?) application:
Unfortunately, compiling the above app as a true 64-bit HELLO64.EXE using Microsoft Visual Studio and then executing it using Wine doesn't work. The problem is that the calling convention for functions is different between MSVC and GCC generated apps. Basically, MSVC puts the function arguments in registers RCX, RDX, R8, R9 while GCC puts function arguments in registers RDI, RSI, RDX, RCX, R8, R9. I guess we'll have to wait for true .EXE support until someone teaches GCC the MSVC calling convention.
To prevent confusion: the "normal" 32-bit Wine version runs fine on x86_64 Linux. This is the version you'll want to use, it allows you to run 32-bit Windows stuff. The remarks above are about running 64-bit Windows executables which are virtually nonexistent at the moment.
Kuba Ober agreed to take a stab at looking into the GCC side of things as long as some people could help test:
I'm currently hacking on gcc for an embedded target (Z8 Encore), but I wouldn't mind giving it a try while I'm digging in the gcc tree.
I'd like to hear any suggestions as to how to tell the compiler to use that calling convention (I'm not talking about implementation, just how the compiler used would tell it).
I presume it'd need to be something that can be set globally per each compiler invocation, as well as a per declaration override.
I'm thinking of "-msvc" (like -liberty ;) compiler option to force a MSVC-compatible ABI, and for now that'd only apply to 64 bit code (i.e. with -m64). Maybe in the future it could enable something special for 32 bit code as well.
I'm all ears about the per-declaration override (a pragma? an __attribute__?), and about alternatives to -msvc.
I'd be submitting a patch to mingw32 people as soon as it's done, in addition to posting it here. Note that the only way for me to test it would be to inspect the assembly output, as I'm not running a 64 bit environment here (even though I'm on a 64 bit AMD processor). So it'd need testing from 64 bit people here at least.
Filip Navara then jumped in to discuss some of the eccentricities of Win64, The problem is not only with the calling convention, but with the whole ABI rather. I've had GCC patched to use the MSVC x64 calling convention (without a switch though) for about a year now, but it doesn't solve the problem. There is much more ABI differences including the exception handling (and yes, I mean exception handling in C, not only C++) where MSVC generates special unwinding information for the functions. I'm not sure if it would be even possible to mix the ABI this way, but I'm open to some suggestions.
As for the documentation I can recommend
More patches from Ge arrived over the next few days, but it seems like there's more work to be done.
|DWARF2 Testing Needed||Archive|
A few weeks ago we mentioned Eric Pouech had added support for the DWARF2 debugging format to Wine (see WWN #317 ). He followed that up with a request for testers:
As you may have seen, there's now some support for the dwarf2 debug format (instead of stabs) in the Wine tree. I'd like to get some feedback on the overall feedback on how it behaves. To do so, you need to reconfigure Wine with something like CFLAGS="$CFLAGS -gdwarf-2" ./configure and then make clean; make (so that all modules are recompiled with proper format) Normal debugging should be available with winedbg. If something goes wrong, please indicate:
Paul Romanyszyn found a problem:
Running a 16 bit application from bug 5493 now gives an a continuous list of
instead of continuous page faulting between on the lookup. What traces do you need and I will add them to that bug.
That bugs url links to the zip of the exe's with instructions on how to reproduce.
Eric posted a patch, but it only uncovered another problem. He promised to fix it later.
James Hawkins sent a patch to indent relay traces:
I don't know if you've ever wished the relay traces were indented by the level of the call, so you can get a better feel for who calls what from where, but I thought it would be nifty. I've attached a patch for dlls/ntdll/relay.c that gives you this. You see the call level next to the thread id, then twice that number of spaces, then the usual relay information. I'd paste an example, but it would just get line wrapped, so patch your tree and give it a shot!
Eric Pouech pointed out there was already a way to do this using a script in tools/ :
This won't work for a multithreaded program. tools/examine_relay does what you want, plus some other goodies (calls that didn't return...) IMO it's better to instrument the tools after the relay trace, rather than tweaking the trace generation for any potential goodie.
Duane Clark added:
It is also not immediately obvious that it will indent in two slightly different formats. Add a flag to the end of the command line to get different formatting:
GUIDs, Globally Unique Identifiers, on Windows are used for all sort of things, including identifying various components. Detlef Riekenberg provided a link to a site that catalogs a ton of them:
Found a big online GUID-List:
All Kernel Cousin issues and summaries are copyright their original authors, and distributed
under the terms of the
GNU General Public License, version 2.0.