WWN Issue 317

This is the 317th issue of the Wine Weekly News publication. Its main goal is to have a party. 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, 201 posts consumed 398 K. There were 77 different contributors. 37 (48%) posted more than once. 32 (41%) posted last week too.

The top 5 posters of the week were:

20 posts in 20K by mike at plan99.net (Mike Hearn)
15 posts in 15K by julliard at winehq.org (Alexandre Julliard)
12 posts in 13K by dmitry at codeweavers.com (Dmitry Timoshkov)
8 posts in 15K by saulius2 at ar.fi.lt (Saulius Krasuckas)
7 posts in 7K by mike at codeweavers.com (Mike McCormack)

News: Linux.com Article	Archive
News An article by Nathan Willis appeared on Linux.com last week titled, Wine Doors opens Windows under Linux . There's a lot of good information in there and it nicely summarizes some of the things going on in Wine development. It also discusses a new application being developed independently from Wine called Wine Doors : Like WineTools, Wine Doors is designed to user-friendlify your Wine installation -- setting up phony Windows drives, adding Windows applications, and so on. The goal is to let users manage their Wine-based apps with point-and-click ease -- from free apps such as Google Earth to closed, commercial software like Photoshop or Internet Explorer -- as well as support packages like font packs supplied by Microsoft. ... Wine Doors' installer module utilizes "application packs," which are XML-based recipes that specify configuration options, prerequisites, file permissions, and other meta-data -- much like native Linux .rpm and .deb package formats. The Wine Doors application itself can retrieve application packs and pack lists from remote repositories, maintaining a local cache for the sake of speed. Wine Doors can thus be integrated with the existing Wine project's AppDB, akin to the way Debian-based Linux distributions link to remote repositories with APT. But that's not all. Lattimer is quick to emphasize that third-party independent software vendors can create and maintain their own application repositories. In corporate environments, he says, the ability to deploy a private repository is important to systems administrators -- and corporate environments often rely more heavily on Wine to transition their desktops to Linux than do individual home users. We briefly touched on the original idea of Wine Doors a few months ago in WWN #308 , but the thread continued on after that. It looks as though things are going well for the project. Finally, a beta of Google Earth 4 is available for download. This news actually has nothing to do with Wine; the port is completely native and uses OpenGL and Qt. For those of you who've downloaded it, here's some stuff to play with. Finally, I stumbled across the Alky project this week. They're trying to come up with a different way to run Windows binaries on Linux/MacOS.

News: Linux.com Article

Archive

News

An article by Nathan Willis appeared on Linux.com last week titled, Wine Doors opens Windows under Linux . There's a lot of good information in there and it nicely summarizes some of the things going on in Wine development. It also discusses a new application being developed independently from Wine called Wine Doors :

Like WineTools, Wine Doors is designed to user-friendlify your Wine installation -- setting up phony Windows drives, adding Windows applications, and so on. The goal is to let users manage their Wine-based apps with point-and-click ease -- from free apps such as Google Earth to closed, commercial software like Photoshop or Internet Explorer -- as well as support packages like font packs supplied by Microsoft.

...

Wine Doors' installer module utilizes "application packs," which are XML-based recipes that specify configuration options, prerequisites, file permissions, and other meta-data -- much like native Linux .rpm and .deb package formats. The Wine Doors application itself can retrieve application packs and pack lists from remote repositories, maintaining a local cache for the sake of speed.

Wine Doors can thus be integrated with the existing Wine project's AppDB, akin to the way Debian-based Linux distributions link to remote repositories with APT. But that's not all. Lattimer is quick to emphasize that third-party independent software vendors can create and maintain their own application repositories. In corporate environments, he says, the ability to deploy a private repository is important to systems administrators -- and corporate environments often rely more heavily on Wine to transition their desktops to Linux than do individual home users.

We briefly touched on the original idea of Wine Doors a few months ago in WWN #308 , but the thread continued on after that. It looks as though things are going well for the project.

Finally, a beta of Google Earth 4 is available for download. This news actually has nothing to do with Wine; the port is completely native and uses OpenGL and Qt. For those of you who've downloaded it, here's some stuff to play with.

Finally, I stumbled across the Alky project this week. They're trying to come up with a different way to run Windows binaries on Linux/MacOS.

Safedisc Support Revisited	Archive
Architecture You might remember last year a lot of work was done to implement ntoskrnl.exe last year. On Windows NT systems that's what would typically be thought of as the kernel. On Wine, it's, um, nothing right now. We use wineserver to synchronize across processes instead. It seems copy protection methods need to do things like load special drivers and that in turn requires ntoskrnl.exe to have some basic functionality. So, last year work was done to create a basic version of it (see WWN #270 , #289 , and #290 for more details.) In the end, the mechanism that was developed was sufficient for copy protection. There was one little problem though: Alexandre didn't quite like the final design. On Windows there's a concept of I/O request packets (IRP) used by the Windows Driver Model to communicate with the operating system. A few months ago Ivan Leo Puoti described the issue with the implementation used by Wine's ntoskrnl: Well we never actually wrote a real irp queue system, we simply had a single irp stack allocated irp struct that we recycled for each call. The whole thing works quite well, the only real issue is that Alexandre decided last December he didn't like the idea of using named pipes for ntdll to ntoskrnl IPC (ntosknrl runs as an independent process), and wanted the whole thing rewritten using the wineserver portocol, which is sort of time consuming and I won't be able to do it before summer. If you want to look over it I can send you what we currently have. Apparently Vitaliy Margolen picked it up recently and announced some changes: Here is latest instalment of safedisc support in Wine. The major change from last version is the way user space talks to ntoskrnl. Now I'm passing the information through wineserver with a help of 4 server calls. There are still some areas that require work. I will appreciate any input that you guys might have about any part of this code. It's been on my lap for way too long. It would be really cool to finally get it in.

Safedisc Support Revisited

Archive

Architecture

You might remember last year a lot of work was done to implement ntoskrnl.exe last year. On Windows NT systems that's what would typically be thought of as the kernel. On Wine, it's, um, nothing right now. We use wineserver to synchronize across processes instead. It seems copy protection methods need to do things like load special drivers and that in turn requires ntoskrnl.exe to have some basic functionality. So, last year work was done to create a basic version of it (see WWN #270 , #289 , and #290 for more details.)

In the end, the mechanism that was developed was sufficient for copy protection. There was one little problem though: Alexandre didn't quite like the final design. On Windows there's a concept of I/O request packets (IRP) used by the Windows Driver Model to communicate with the operating system. A few months ago Ivan Leo Puoti described the issue with the implementation used by Wine's ntoskrnl:

Well we never actually wrote a real irp queue system, we simply had a single irp stack allocated irp struct that we recycled for each call. The whole thing works quite well, the only real issue is that Alexandre decided last December he didn't like the idea of using named pipes for ntdll to ntoskrnl IPC (ntosknrl runs as an independent process), and wanted the whole thing rewritten using the wineserver portocol, which is sort of time consuming and I won't be able to do it before summer. If you want to look over it I can send you what we currently have.

Apparently Vitaliy Margolen picked it up recently and announced some changes:

Here is latest instalment of safedisc support in Wine.

The major change from last version is the way user space talks to ntoskrnl. Now I'm passing the information through wineserver with a help of 4 server calls.

There are still some areas that require work.

I will appreciate any input that you guys might have about any part of this code. It's been on my lap for way too long. It would be really cool to finally get it in.

Vertex Buffer Objects	Archive
DirectX Direct3D work continues to steamroll along. Stefan Dösinger announced work this week to add vertex buffer objects to WineD3D: In the last days I've been working on using the OpenGL vertex buffer objects extension for IWineD3DVertexBuffer. The aims of this were: Store geometry data in the hardware for more efficient rendering Convert the colors and rhw values on upload and get rid of drawStridedSlow The result is in this diff, and it basically works, although not as good as I've hoped. It gives a nice performance boost to Battlefield 1942, and is an improvement for Half-Life 2, but it is not perfect yet. The main shortcomings are: Shader support: I'm afraid that the conversion code at this points breaks shaders. I've tested with battlefield 1942. The vertex shaders in this game don't work correctly yet, the hands of soldiers are missing and there are some incorrect planes with odd colors. However, with this patch the hands are drawn as apparently random vertices all over the screen. I think I'll need a little help from the shader people for that. The vertex conversion is slow, and it turned out that if the app Locks the Buffer every frame then drawStridedSlow is faster Converting + drawStridedSlow. Because of that VBOs and the conversion aren't used for vertex buffers in system memory and vbs with WINED3DUSAGE_DYNAMIC are not loaded into a vbo. In Direct3D7 there is no way for the app to specify a range of vertices to be locked. Because of that DX7 apps are generally slower if they update the vertices regularly. To avoid that drawback there is no VBO created for DX7 apps if they have vertex data that needs conversion. The geometry in DX7 apps is usually quite simple, so DrawStridedSlow isn't a big performance hit in those apps. Then a few days later Stefan updated the patch: This is an updated version of the VBO patch. The main difference is the integration with IWineD3DDevice::ProcessVertices which gives a nice performance boost for Half-Life 1 and probably Anarchy Online (not tested yet). What is missing is work with vertex shaders (awaiting the download of the dx8 sdk for the dolphin demo) and an implementation of IDirect3DVertexbuffer7::ProcessVertices.

Vertex Buffer Objects

Archive

DirectX

Direct3D work continues to steamroll along. Stefan Dösinger announced work this week to add vertex buffer objects to WineD3D:

In the last days I've been working on using the OpenGL vertex buffer objects extension for IWineD3DVertexBuffer. The aims of this were:

Store geometry data in the hardware for more efficient rendering
Convert the colors and rhw values on upload and get rid of drawStridedSlow

The result is in this diff, and it basically works, although not as good as I've hoped. It gives a nice performance boost to Battlefield 1942, and is an improvement for Half-Life 2, but it is not perfect yet. The main shortcomings are:

Shader support: I'm afraid that the conversion code at this points breaks shaders. I've tested with battlefield 1942. The vertex shaders in this game don't work correctly yet, the hands of soldiers are missing and there are some incorrect planes with odd colors. However, with this patch the hands are drawn as apparently random vertices all over the screen. I think I'll need a little help from the shader people for that.
The vertex conversion is slow, and it turned out that if the app Locks the Buffer every frame then drawStridedSlow is faster Converting + drawStridedSlow. Because of that VBOs and the conversion aren't used for vertex buffers in system memory and vbs with WINED3DUSAGE_DYNAMIC are not loaded into a vbo.
In Direct3D7 there is no way for the app to specify a range of vertices to be locked. Because of that DX7 apps are generally slower if they update the vertices regularly. To avoid that drawback there is no VBO created for DX7 apps if they have vertex data that needs conversion. The geometry in DX7 apps is usually quite simple, so DrawStridedSlow isn't a big performance hit in those apps.

Then a few days later Stefan updated the patch:

This is an updated version of the VBO patch. The main difference is the integration with IWineD3DDevice::ProcessVertices which gives a nice performance boost for Half-Life 1 and probably Anarchy Online (not tested yet).

What is missing is work with vertex shaders (awaiting the download of the dx8 sdk for the dolphin demo) and an implementation of IDirect3DVertexbuffer7::ProcessVertices.

Wine on 64-bit AMD / Ubuntu Archive

Wine on 64-bit AMD / Ubuntu	Archive
Ports David Anderson wrote in with a step-by-step guide to getting Wine to build on an AMD-64 system using Kubuntu 6.06 (Dapper Drake): I finally got around to finishing a build, with current cvs sources. First one must install the necessary libraries: Finding the correct set may take a few minutes and several tries. `configure` will find several omissions, but a few will only be noticed by the 'make' steps. The following is links that the library install does not make: Do this by hand, it won't work as a script as written. `sudo sh` `cd /usr/lib32` `ln -s libX11.so.6 libX11.so` `ln -s libXext.so.6 libXext.so` [Then you can compile: ] `LDFLAGS="-L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32" ./configure` `make depend` `make all` `sudo make install` If all needed libraries are present there will be no missing-library warnings or errors anywhere. wine seems to work (installed in /usr/local) Scott Ritchie, the Ubuntu/Debian package maintainer, thanked him for it: It's basically a step-by-step to rewriting the build script to work on AMD-64 for the packages. I'll try hacking around with it once 0.9.16 comes out. I suspect, however, that doing it this way doesn't include EVERY lib that Wine can use properly, as there are still some libs missing from the 32bitlibs package in Ubuntu.

Ports

David Anderson wrote in with a step-by-step guide to getting Wine to build on an AMD-64 system using Kubuntu 6.06 (Dapper Drake):

I finally got around to finishing a build, with current cvs sources. First one must install the necessary libraries: Finding the correct set may take a few minutes and several tries.

configure will find several omissions, but a few will only be noticed by the 'make' steps.

The following is links that the library install does not make: Do this by hand, it won't work as a script as written.

sudo sh
cd /usr/lib32
ln -s libX11.so.6 libX11.so
ln -s libXext.so.6 libXext.so

[Then you can compile: ]

LDFLAGS="-L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32" ./configure
make depend
make all
sudo make install

If all needed libraries are present there will be no missing-library warnings or errors anywhere. wine seems to work (installed in /usr/local)

Scott Ritchie, the Ubuntu/Debian package maintainer, thanked him for it:

It's basically a step-by-step to rewriting the build script to work on AMD-64 for the packages. I'll try hacking around with it once 0.9.16 comes out.

I suspect, however, that doing it this way doesn't include EVERY lib that Wine can use properly, as there are still some libs missing from the 32bitlibs package in Ubuntu.

DWARF2 Debugging	Archive
Debugging As of GCC v3, the standard debugging format has been DWARF 2 . Raphael Junqeira did some working on Wine's debugger to support it and announced the following changes: Changelog: map lines section better robustness support of unamed syms better traces ref hash table to stabilize model TODO: find a clean way to handle forward declarations (some assertions can happen) debug lines parsing Eric Pouech replied he had also been working on the same thing: I did (in parallel) some work on the dwarf2 support. I have 20+ patches to make it really work. Those patches bring: type support, including forward declarations (which really requires a two pass parser, hence a major rewrite of the code) function's variables & parameter support line information is ok (except for inlined functions) a couple of bug fixes from current code I'd suggest hence not to apply this patch and to wait for the full solution (likely sometime this weekend). He followed that up with 31 patches. He gave a clearer description of the patches before posting them: The following series implements basic support for Dwarf2 debug information. Basically, it's a major rewrite/enhancement of the current code. At the end of the series, we should have: type information (at least basic types, and struct unions) functions's parameter and variable handling (1) line number information What's not working yet: some variables in functions (when using registers) -< will require CFA parsing (and translation into FPO) single stepping through trampolines (cross-DLL calls). BUT, THIS IS BROKEN FOR STABS TOO... Likely, the same issue for both formats missing function's start point -< this means the first insn of the functions will be seen, meaning that you need to do a couple of 'nexti' calls to step over the functions prologue (otherwise you won't see the current function's parameters) inlined functions are not fully handled (meaning that you won't be able to see the inlined function's argument - but this wasn't available in stabs debug info) nested types are not correctly handled

DWARF2 Debugging

Archive

Debugging

As of GCC v3, the standard debugging format has been DWARF 2 . Raphael Junqeira did some working on Wine's debugger to support it and announced the following changes:

Changelog:

map lines section
better robustness
support of unamed syms
better traces
ref hash table to stabilize model

TODO:

find a clean way to handle forward declarations (some assertions can happen)
debug lines parsing

Eric Pouech replied he had also been working on the same thing:

I did (in parallel) some work on the dwarf2 support. I have 20+ patches to make it really work. Those patches bring:

type support, including forward declarations (which really requires a two pass parser, hence a major rewrite of the code)
function's variables & parameter support
line information is ok (except for inlined functions)
a couple of bug fixes from current code

I'd suggest hence not to apply this patch and to wait for the full solution (likely sometime this weekend).

He followed that up with 31 patches. He gave a clearer description of the patches before posting them:

The following series implements basic support for Dwarf2 debug information. Basically, it's a major rewrite/enhancement of the current code. At the end of the series, we should have:

type information (at least basic types, and struct unions)

functions's parameter and variable handling (1)

line number information

What's not working yet:

some variables in functions (when using registers) -< will require CFA parsing (and translation into FPO)
single stepping through trampolines (cross-DLL calls). BUT, THIS IS BROKEN FOR STABS TOO... Likely, the same issue for both formats
missing function's start point -< this means the first insn of the functions will be seen, meaning that you need to do a couple of 'nexti' calls to step over the functions prologue (otherwise you won't see the current function's parameters)
inlined functions are not fully handled (meaning that you won't be able to see the inlined function's argument - but this wasn't available in stabs debug info)
nested types are not correctly handled

World Wine News