Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Wine Traffic #317 For 19 Jun 

By Brian Vincent

Table Of Contents

Introduction

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

Mailing List Stats For This Week

We looked at 201 posts in 398K.

There were 77 different contributors. 37 posted more than once. 32 posted last week too.

The top posters of the week were:

1. News: Linux.com Article

(1 post) Archive Link: "News"

Topics: News

People: Linux.comMicrosoftNewsGoogle

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 things going on in Wine development. It also discusses a new application being developed independent of 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.

2. Safedisc Support Revisited

(1 post) Archive Link: "One more shot at ntoskrnl implementation"

Topics: Architecture

People: Ivan Leo PuotiVitaliy Margolen

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

3. Vertex Buffer Objects

(5 posts) Archive Link: "Vertex Buffer Objects for WineD3D"

Topics: DirectX

People: Stefan Dosinger

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:

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:

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

4. Wine on 64-bit AMD / Ubuntu

(2 posts) Archive Link: "Build on kubuntu 6.06,amd_64 works"

Topics: Ports

People: David AndersonScott Ritchiecvs

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.

  1. sudo sh
  2. cd /usr/lib32
  3. ln -s libX11.so.6 libX11.so
  4. ln -s libXext.so.6 libXext.so

[Then you can compile:]

  1. LDFLAGS="-L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32" ./configure
  2. make depend
  3. make all
  4. 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.

5. DWARF2 Debugging

(3 posts) Archive Link: "[PATCH 00/31] Series short description"

Topics: Debugging

People: Raphael JunqueiraEric Pouech

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:

TODO:

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:

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

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

The following series implements a basic support for Dwarf2 debug information. Basically, it's a major rewrite/enhancement of the current code. At the end of the serie, 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:

     

     

     

     

     

     

    Sharon And Joy
     

    Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.