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.

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.

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.

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

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.

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)

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.

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

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 sometimes this weekend).

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:

• 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