• Better Web browser support.
• Beginnings of a Wordpad application.
• Many richedit improvements.
• A number of Direct3D fixes.
• A few more options in winecfg.

This patch is based on Oliver Stieber his D3D8->WineD3D work and adds the CopyRects method required by D3D8 to WineD3D.

This is the first part of a 1700 line patch (based on Oliver Stieber's d3d8 work) which moves big portions of the D3D8 surface code over to WineD3D.

It moves the d3d8 surface structure over to wined3d. As moving all code over in one step to wined3d is not a good idea the old d3d8 code had to be made compatible with the new structure. This change required me to import some structures from the wined3d_private.h header untill the move is over (the wined3d header can't be included by d3d8 as it conflicts with d3d8_private.h). Further some pieces of surface code were moved over to wined3d.

This patch (based on Oliver Stieber's d3d8 code) moves d3d8's texturing code over to WineD3D. The patch adds new datatypes, replaces a few texture creation calls with wined3d code and updates code to work with the new datatypes. Unfortunately the patch is quite big because there's one texture base type of which all other texture types are instances.

Both our d3d8 and wined3d dlls contain a routine which detects the capabilities of the videocard as advertised by the OpenGL driver. Right now varies parts of D3D8 have been moved over to WineD3D. Varies pieces of the code ported to WineD3D use these capabilites. Right now D3D8 contains a list with capabilities but doesn't share it with WineD3D. Because of this some pieces of code failed for instance wined3d's surface code for each I posted a workaround last week.

This patch moves the capability detection code over to WineD3D and lets the few existing parts which need the capabiliteis use the WineD3D capability structure (gl_info). This info structure contains next to 'flags' inidicating certain features also all GL/GLX functions pointers. Because D3D8 moves over to the wined3d gl_info structure all the gl prototypes in d3dcore_gl.h were unneeded and removed.

The past few weeks I have trying to split Oliver Stieber's d3d8 patches in small pieces. The patches I sent so far me oved big parts of the surface, texture and capability detection code over to wined3d (roughly 1/3th of the total patch) These parts could safely be moved as they didn't depend on much other d3d8/wined3d functionality. The remaining texture, shader, primitive drawing code depends on stateblocks and swapchains which haven't been ported over yet. If I would move over for instance the remaining texture code the stateblock/swapchain code needs to moved too. The current d3d8 shader code would need to be made compatible with the wined3d stateblocks (which isn't possible becaue various datatypes in the stateblock changed; the wined3d stateblock uses incompatible wined3d datatypes which the shader code doesn't understand)

Other parts of the d3d8 code have similar issues, so they all depend on the stateblock/swapchain code. The only option is to move all this code at once. I talked with H. Verbeet and others and they thought that separating is nearly impossible too. (splitting would create too many new bugs and not everything is moveable)

The patch which I attached to this email removes the remaning d3d8 code over to WineD3D. (based on Oliver Stieber's code) The file d3d8.patch.bz2 makes changes to the current d3d8 code and also makes a few changes to wined3d in order to let wined3d create various objects for d3d8. The other two files need to be added to the d3d8 directory and replace the current shader code. As you will notice in the Makefile.in various d3d8 files aren't used anymore a next patch will clean up the d3d8_private.h file and remove the unneeded .c files.

Just wanted to report my wine experience with Lotus Notes 6.5.1: I've run Lotus Notes with wine for a long time. What I notice with wine-0.9.8 (though this was present in a few releases before but not in all releases):

• Wine is noticably faster than the snapshot 200412xx
• I need to select win98 to get the file select box working
• I need to set WINEDLLOVERRIDES="usp10=n"
• Cut and paste between X and wine applications works only when selecting the appropriate entry in KDE's klipper. Previously, that worked transparently, when specifying "UsePrimary" = "1" in the [Clipboard] config stanza
• The file select box shows for folders the symbol of files, e.g.

configure: Use --rpath if supported when building binaries to point to the relative location of the wine libraries.

It is only useful when we run wine from the source tree.

There is no need for rpath if libwine is placed in a standard place such as /usr/lib

I got follow broken requires when build rpm package:

/usr/bin/../lib/libwine.so.1(WINE_1.0) /usr/bin/../lib/libwine_unicode.so.1(WINE_1.0)

It sounds like rpm needs a good whack on the head if it is unable to cope with this. Anyway, you could always build with make LDEXERPATH="".

I decided to make this release a bit more complete than the other ones i did before. Bugfree (i hope ;)) and with readme. current version is 0.2.

This is the readme's content:

Intro

getwinegit is a script which was designed to download/update, compile and install the current wine-git-source-tree.

Usage

Usage: /usr/bin/getwinegit.sh -<mode>

modes:

-0 update the local source-tree
-1 + compile the source
-2 + install
-3 no update; just compile the local source-tree and install
-h help ;)

Install

Just copy getwinegit.sh wherever you want, make it executable and create a softlink at /usr/bin. Then (or before) configure the script by editing the variables in the head with your favourite editor. (minimum is to set ENABLE="yes")

Changes

0.2 first stable release.

Future?

Tell me what you need and i will implement it... maybe :D

I have been looking at a problem that has arisen in recent versions, particularly when using some D3D games, in which the virtual address space above TASK_UNMAPPED_BASE becomes fragmented to the extent that eventually you get an out of memory condition, even though you still have well over a gigabyte free (even in a contiguous block!). This has led to some people using the attached hack (first attachment) to get their D3D games to work.

After considering a lot of approaches to this problem that did not seem to get anywhere productive, it seemed that the only way to resolve it would be to get in between the application and any libraries, and the kernel. The solution I came up with is somewhat rude, but if we assume that any libraries that Wine uses only call mmap() and associated calls via the C library, then it may well do the trick, plus make it possible to implement other virtual memory APIs more effectively (and in a couple of cases eliminate calls to wineserver).

If wine_preloader were extended to have its own implementation of all the friends of mmap(), and to have its own implementation of the dynamic linker, then in principle it could make sure only its mmap (and not the C library's) is called. An even more aggressive approach might be to load the C library and stick jumps into its mmap that redirect to the preloader's versions. The preloader's mmap would keep track of mappings on its own and when it receives an mmap with a start address of "NULL", decides on its own what base address to use.

You can override mmap() in wine by just changing all the places it's called. (Having control over the source is a wonderful thing.) But if you want mmap to behave truly differently, you'd probably need to change the kernel.

I seem to recall somebody was working on a linux kernel module for wine that just dealt with program loading, but I can't recall who. Perhaps he'll surface and comment on this.

You can do that easily after glibc has loaded, but you won't know where glibc itself was loaded into the address space.

I discussed something like what Troy proposed with Vitaliy on IRC, but with the preloader looking up and overriding the mmap/munmap symbols in glibc. That would hopefully give Wine control over most mmaps and munmaps, possible save us from having to reserve memory in the preloader, and allow more control of the address space.

It has a few problems though. Firstly, we'd miss mmaps done with system calls. Secondly, we'd have to make assumptions about what areas of memory the kernel would let us map, and what areas of memory were already used in the address map.

I had a go at creating a kernel based PE loader for Linux 2.6 by forward porting parts of David Howell's Wine kernel module. It currently compiles, but that's about all.

Haven't had much time to spend on it lately, because I've been busy with work.

We are interested in getting the new Guitar Rig 2 USB foot controller supported in Linux/Wine. It's described here:

http://www.native-instruments.com/index.php?id=guitarrig2_us

I assume from looking at it, that a USB driver would be required and then perhaps some Wine tweaks to let the plugin open the USB driver.

Anyone interested in taking this on? We are hoping to do this as a trade --- like you do this work and get a Receptor and/or some VST plugins for your time.

BTW, we also have a job opening, posted here:

http://www.craigslist.org/pen/sof/132110028.html

A guy from the linux-audio developers mailing list named Brian Sturk replied and is interested in doing the work. He should be fine with the linux driver side, but pointers in the Wine part of the project might be useful.

For now, I am assuming that the work would be open source and integrated into linux and wine in the normal way. I believe the company will be cooperative.