World Wine News

• Many new features and improvements in Richedit.
• More Web browser support.
• Recursive directory change notifications.
• Wine installation is now fully relocatable.
• Direct3D 8 and 9 now use the same code.
• Many debugger improvements.
• Systray is now handled by the explorer process.

Valgrind is a set of tools aimed at finding bugs in programs. For example, the tool memcheck allows to identify read access to a memory location which hasn't been initialized, which is handy in some cases.

Since Wine uses a lots of tricks to run, Valgrind didn't behave well with Wine. To make a long story short, Valgrind takes the binary code of any program, translated into an intermediary binary code of its own, inserts the checks required (for example for memcheck, it traces every read and write operation to memory), and then generates back the binary code for the target processor. This also requires lots of action for a smooth integration with the OS (intercepting the system calls, getting a knowledge of the threads...).

The good news (now), is that Valgrind 3.1.0 runs out of the box on Wine. Even if there was a specific port of Valgrind (2.x) to run under Wine, we strongly suggest using Valgrind 3.1.0.

A summary of where we stand for making Valgrind and Wine work well together. The starting point is Valgrind 3.1.0 and Wine 0.9.7.

First of all (reminder) Valgrind & Wine now work (mostly) out of the box together.

Here's a list of (known) problems faced:

1. missing support for some ioctls (HDMA, serial). Added to Valgrind (now in branch, at least of x86)
2. missing support for tkill syscall. Added to Valgrind (now in branch), Wine fixed to use the better tgkill syscall (0.9.8)
3. some missing instrumentation of Wine (regarding stack manipulation). Wine fixed (0.9.8)
4. possibility to change EIP in signal handler. Added to Valgrind (now in branch, for x86).
5. trapno is not passed in signal handlers. A hacky patch proposed, and rightfully rejected. Solution in sight (Tom Hughes), not yet in branch.
6. missing instruction emulation in VEX (x86, and likely amd 64). Wine needs:
   push/pop [ds,es,ss]
   iret (on 32bit intercall, cs not changed)(*)
   int 3
   cli/sti
   (*) actually, Wine would require much more for 16bit emulation, but I don't think it's reasonable, nor a short term goal, to use Valgrind & Wine for 16bit code.
   The push/pop code was easy to fix (it's already written). However iret will be a bit trickier (I have a dirty hack for iret and int 3, but likely Julian would rather do it himself ;-). We can try to get rid of the cli/sti pair.
7. missing stack backtrace information

   As already explained, the first thread of a process is handled as follows: it starts using the stack created from the process creation (from Unix). As the process may require a larger stack (from the Windows definition of the PE header), the Wine loader always create a second stack at the loader startup, and switch execution to that second stack when calling the PE module entry point.

   The outcome of this, from a Valgrind point of view, is that we get two stacks (values are important):

   • first stack at 0xBE??????
   • second stack at 0x20?????? (ie below the first one).
   The second stack is declared to Valgrind by Wine. When Valgrind needs to print a backtrace (for any issue), in get_StackTrace2 there's a test:
   if (fp_min + VG_(clo_max_stackframe) <= fp_max) {
   Here fp_min gets its value from the second stack (in the 0x20?????? area, and fp_max in the 0xbe?????? area). The outcome is that no backtrace is generated :-/. Trying to remove the test (or increase the max_stackframe value) provides some other issues as not all the area in the 0x20????? - 0xbe000000 is mapped, hence having some crashes.

   This one is a bit more hairy to fix. I have a patch that mixes the max_stackframe test, with some extra test about the stacks that are known by Valgrind (and checking that info for the backtrace really points to the stack). But since Valgrind doesn't make use of this information, it must be for good reasons.

The net result of this is:

• because of 7., we cannot get a full backtrace of an issue found by Valgrind. Currently, we disabled the offending test in get_StackTrace2 pointed out in 7. With the listed side effects (crashes), and we'd like to have something working out of the box (from the Valgrind branches)
• because of 5. and 6., we cannot use Wine and Valgrind on programs triggering exceptions (the missing parts in 5. and 6. are only used in those occasions).

I'd really like to see 5., 6. and 7. fixed. Let me know if you need some help.

The good side of the story:

• we ran the regression tests (from the Wine regression test suite) on 5 DLLs under Valgrind, and fixed something like 15 potential issues and bugs (even if some tests don't work under Valgrind yet)
• that's worth going further and run the full Wine regression tests under Valgrind.

I've brought my DirectDraw over WineD3D patch in a form where I want to show it to the public for review. I've uploaded it to http://stud4.tuwien.ac.at/~e0526822/ , where it is described in detail (below the game list).

If there are no fundamental objections against it, I'll start sending patches for WineD3D. The changes I'll make in small patches :) are:

• Header fixes, that wined3d_interface.h can be included with d3d.h
• Adding methods to WineD3D for DirectDraw rendering
• Adding the 2D only surface implementation to WineD3D

When WineD3D is ready, I'll send a patch for dlls/ddraw to wine-devel and wine-user for a broad regression testing, and when the regressions are out, the ddraw can be replaced (From my POV, AJ has the last word of course ;) )

Basically all rendering and screen setup is done in WineD3D, and all DirectDraw and Direct3D7 specific management is handled in ddraw. Because of that, the ddraw.dll is much bigger, compared to d3d8.dll or d3d9.dll. It handles the decoding of the horrible DirectDraw data types, thunks and wrappers for older DirectDraw and Direct3D interface versions as well as many DirectDraw-specific things as surface attachments and complex surfaces. Screen setup and rendering is done in WineD3D.

There are a few changes to WineD3D:

• Initialization is split up in an OpenGL-free part and an IWineD3DDevice::Init3D method which initializes the 3D functions. This split is not yet complete, so an opengl lib must be installed and some ddraw games (nfs3) crash in opengl calls called during initialization. The IWineD3DDevice::Relase code has been split up too. IWineD3DDevice has methods to setup the screen without a Direct3D swapchain
• An second surface implementation was added, IWineX11Surface, which handles 2D only-operations with the old surface_dib code. It will be renamed to WineGDISurface, and WineX11Surface will use Xrender, WineD3DSurface will get the ability to do 2D rendering with OpenGL
• DirectDraw rendering methods such as IWineD3DSurface::Blt, IWineD3DSurface::BltFast and IWineD3DSurface::Flip have been added, along with related calls.
• Some DirectDraw data types will be added to include/wine/wined3d_types.h, and d3d9 types which are used by the wined3d header and don't exist in d3d.h will be added to wined3d_types too. At the moment, those definitions reside in dlls/ddraw/d3d_compat.h.

Is it possible to set Wine up so that it can launch native Linux apps? For example, set your native copy of Acrobat Reader to be associated to PDF extensions in Wine, or even use the Linux plugin while using a browser?

I have done this with Kmail and others. You have to add a few registry keys in HKCL and HKLM. Basically, you can launch any Linux app from wine by its full path and pass command line arguments. There's of course the problem of converting Windows paths to Unix paths.

At http://www.winehq.com/fun_projects my Kmail registry entries are described. For examples how to use Open Office, you have to google.

I don't think that executing a Linux Plugin in a Win32 browser is possible, but CrossOver allows you to do the reverse.

We've run into a bit of a snag around WineConf 2006.

Huw was trying to pull something together for this summer, but he's asked to beg off (he's going to be out with a thyroid operation for a bit; prognosis looks good, but...).

Rob stepped up and volunteered to pull something together in Reading in the UK, and has been a good sport about getting it together.

Sadly, the dates haven't been working out very well.

Rob and I were trying to get something together for May 13th (all other dates in May don't work for one reason or another), but then internal folks here started telling us that that was way too soon.

The problem with trying for June is that travel costs in June are astronomical; plane flights for example are twice the cost in June than in May.

So what I'd like to ask is that people that are interested in coming to WineConf give us a bit of feedback:

http://www.winehq.org/wineconf/survey06

Also, I'd like to request that follow ups to this shift over to the WineConf mailing list:

http://www.winehq.org/mailman/listinfo/wineconf

For those of you that don't know, WineConf is our kinda sorta annual technical conference. It's a place where Wine developers gather to heckle Alexandre, talk about the mythical Wine 1.0, and marvel that there are 60 other people as crazy as themselves <grin>.

There isn't usually any fee, although you have to bear your own travel costs. Everyone is welcome, but the focus is very technical and developer focused, so 'regular' users may feel a bit out of place.