Wine Traffic #318 For 10 Jul 

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.

some of you might have noticed that building 0.9.16 for Fedora Extras took me more time then the releases before. This was because of the discussions from a couple of weeks ago on this list. As a result I did spent 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 relation ship 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.

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 virusscanner 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:

1. searching /proc/self/fd/%d for the name. This would be an easy but very ugly solution.
2. maintaining a table mapping unix_handles to filenames from within NtCreateFile(). Hence I don't have the feeling that this is a good solution.
3. storing the unix filename in the wineserver handle object when it's created. This is probably the right place to keep this information but it would require some changes to the wineserver. If I understand it right it is already planned to implement something like this ("lookup_name" in server/object.c)

But maybe I just missed an even better approach. What would you recommend to do? Any comment is appreciated.

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?

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

http://www003.portalis.it/115/wine-safedisc-0.9.16-mdk.i586.rpm

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.

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:

#include "windows.h"
int WINAPI WinMain(HINSTANCE hinst, HINSTANCE hprev, LPSTR cmdline, int cmdshow)
{
DWORD Written;

WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), "Hello, world\r\n", 14, &Written, NULL);

return 0;
}

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 non-existant at the moment.

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 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.

As for the documentation I can recommend

• http://blogs.msdn.com/freik/archive/category/12430.aspx (http://blogs.msdn.com/freik/archive/category/12430.aspx)
• MSDN
• the PE-COFF v8 document recently updated by MS ( http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx (http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx) )
• the ABI document that comes with some MSVC versions

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:

• console messages
• error items
• steps that led to it
• version of gcc used

Running a 16 bit application from bug 5493 now gives an a continuous list of

fixme:dbghelp_dwarf:dwarf2_compute_location Unhandled attr op: 75

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.

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!

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.

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:

tools/examine_relay wine.log -f

Found a big online GUID-List:

http://www.myplugins.info/guids/guidlist.php (http://www.myplugins.info/guids/guidlist.php)