WINE 1.1.19 Comes With Cleaner Direct3D Code

[phoronix]

Phoronix: WINE 1.1.19 Comes With Cleaner Direct3D Code

In their usual bi-weekly ritual, the open-source WINE developers have released a new version of this software used to run Windows programs on Linux and other operating systems. The latest development release of WINE is version 1.1.19 and it offers support for Visual C++ project files in winemaker, improvements to the Esound driver, many Direct3D code cleanups, fixes to the OLE clipboard handling, and OpenBSD compilation fixes...

http://www.phoronix.com/vr.php?view=NzE5OA

[GreatWalrus]

Sweet, they closed a C++ support bug from the year 2000.

[Kano]

On 64 bit wine it does not create menu links in the .local dir. 32 bit it works. Did somebody experience the same?

[monkeynut]

Do the Direct3D code cleanups make Wine more compatible with games or for the meantime is it just behind the scenes?

[Thunderbird]

The cleanups could help games but in general not. It is more to prepare WineD3D for Direct3D10 support.

[RealNC]

On 64 bit wine it does not create menu links in the .local dir. 32 bit it works. Did somebody experience the same?

It created them when I was on KDE 3. It stopped doing that in KDE 4. I thought it's KDE 4's fault.

[remm]

The Wine devs are totally out of touch with reality though, focusing on ESD rather than integrating available patches ( http://bugs.winehq.org/show_bug.cgi?id=10495 ). It does not really matter though since distros do that for them, but still ... I don't have the impression this project will ever get to a good level of quality.

[Kano]

@RealNC

But i use KDE 3.5. I have got similar installs with 32 and 64 bit lenny + latest wine.

[RealNC]

Then I guess something happened in Wine in latter versions. I clearly remember that Wine on Gentoo 64-bit created its own group in my K-menu where the installed Windows apps could be started from, just like Windows' "Start" menu.

[srg_13]

The Wine devs are totally out of touch with reality though, focusing on ESD rather than integrating available patches ( http://bugs.winehq.org/show_bug.cgi?id=10495 ). It does not really matter though since distros do that for them, but still ... I don't have the impression this project will ever get to a good level of quality.

I doubt they're focusing on Esound - it's far more likley that most of the sound work goes into the Alsa driver. Still, it would be better to just make a driver that interfaces with something like OpenAL or libcamberra, which already has backends for alsa, pulseaudio and jack among others.