World Wine News

• Midi support in the CoreAudio driver.
• Mixer support in the Alsa driver.
• A lot of MSI fixes.
• Implementation for most D3DRM functions.
• The usual assortment of Direct3D fixes.

In Linux, the most used sound backend for Wine is OSS, this is years obsoleted and doesn't work well with modern Linux systems. This is one of the weak sides of Wine, and I want to propose to improve the ALSA sound backend to be as good a backend as OSS, or if possible an even better backend.

This requires changes in the DirectSound emulation code, and in the winealsa driver. I have played around with it before, but as far as I can tell a lot of things need to be changed in the dsound and winealsa code:

• DirectSound doesn't have proper support for secondary buffers at driver level. None of the Wine drivers needed it before, but the directsound software mixer works horrible, I'll try to get that working as well as fallback, but the mixing should really be done in alsa code if possible.
• Locking and Unlocking buffers in directsound doesn't forward to secondary buffers when needed. This is very important for secondary buffers in alsa, as I want to use it for making sound run properly, hopefully it will work.
• Limitation of alsa: buffer size cannot be arbitrarily big, a workaround is needed, most likely buffer emulation in winealsa. This is tricky, as it means writing from 1 bigger buffer into a smaller buffer, since we can assume that in those cases the buffer is big enough that a buffer underflow doesn't happen, it means that we can run a timer that fills the buffer.
• Winealsa currently doesn't have support for AUX and mixer controls. This is needed to manipulate the mixer the same way as it's manipulated under windows and Wine, I don't think it's hard to accomplish but it's worth it for applications that play around with volume controls.
• Remove the separate thread used in winealsa, rework the code so it's not needed any more. The current thread only causes stuttering of audio, it's better to remove it entirely by using alsa lock and unlock calls, which notify that there is some sound that can be played. Alsa then takes care of the playing etc so we wouldn't have to handle it.
• Implement dscapture for winealsa. Sound capture code in alsa currently only exists for wave in, and not for directsound, this means that applications that use dscapture use a lot of cpu to get it working, applications like counter strike source take a deep performance hit from it.
• (Most importantly) Make ALSA run so well, people wouldn't want to use OSS driver any more. No explanation needed. If this is true, ALSA can become the standard driver in Wine (instead of OSS)

Why?

The direct3d code in Wine is getting better and better with each release, games work better and better, but for sound in those games people still use OSS or a badly working ALSA driver. I want to play games on my Linux system and not have to close all other applications to get proper sound, since OSS wants to have exclusive access to sound.

• Implement opening/closing and caps of device
• Introduce mixer code
• Implement mixer controls, and add GetLineInfo
• Implement GetLineControls in mixer
• Implement Get/SetControlDetails in mixer

We have noticed that wine doesn't have the winscard dll responsible for the support of smart cards under windows. For the need of one of our projects, we are currently developing this dll for wine under Linux based on the pcsc-lite library. Once done, we'll share it with the community. However, we would like to know the reason behind the lack of winscard support. Is it simply because no one needed it before or maybe there is an issue with the pcsc-lite license? Thanks in advance for your information.

We have managed to integrate our winscard source code into the wine source tree, including the configure.ac and Makefile.in files. As described in the developer's guide, I am attaching with this email the output of the command "git format-patch origin". Can someone please check if I have done it the right way? If this is ok, should I post it also to the patches mailing list. For your information, our implementation uses pcsc-lite through wine_dlopen and wine_dlsym, so pcsc-lite is not required at compile time.

We have not included test files as they include the use of smart cards with proprietary applications. I will try in the near future to include a wine implementation of a graphical tool that can manipulate smart cards using the wine winscard dll.

From a cursory look, it looks to be a very good start !!!

A couple of comments though:

• some functions are declared (), they should be (void) (it's C, not C++)
• wstrlen already exists: it's strlenW (even if we don't check for NULL strings)
• don't use malloc/free but rather HeapAllocate... in windows, malloc boils down to HeapAllocate through msvcrt, but in Wine it uses the glibc one, which is not what you want
• ConvertListToANSI: IMO, after computing the final length, only a single call to MultiByteToWideChar is necessary (it will convert the whole area)
• ditto for ConvertListToWideChar
• headers:
  • the rule for including new headers in Wine is really to have them fully retyped... looking at the comments in the file, it looks to me you mostly copied the existing headers and their comments as well
  • some types are not the correct ones (at least on my latest SDK) => e.g. you use long for SCARDCONTEXT whereas it's defined as a ULONG_PTR (it will not correctly work when compiling on a 64bit machine) (I'm not saying that your code must be 64 compliant at first, but the headers must be)
• spec file: don't define an entry point if you don't absolutely need it (most of them should still be stubs)
• you still use C++ comments, whereas Wine only allows C comments

from the inclusion into Wine, it's already way too big to be included in a single operation. So, you should split up your work in smaller pieces. For example:

• patch #1-3: new header files
• patch #4: bare DLL infrastructure (mostly .spec file (only stubs), Makefile.in and .c file with DllMain, configure.ac)
• patch #5: a small set of functions XXX (c file, modified .spec file)
• patch #6: a small set of functions YYY (c file, modified .spec file)

It would be also interesting to think about having several C files for the DLL (given the number of APIs to implement)

Finally, it seems that the DLL exports some variables => they have to be specially handled (see details on how to do it in some other DLLs, like msvcrt)

I just upgraded to the latest wine version and tried wineprefixcreate (no .wine directory), and it kills X. Nvidia drivers 1.0.9755.

Anyone else see this?

Day 1

SambaXP started on monday with a tutorial from Jerry Carter, which was interesting but not really related to Wine. However, in the evening I finally managed to grab hold of Steve French to talk about implementing a remote named pipes interface in cifs. This afternoon, the actual conference is about to start, featuring a couple of talks about winbind, cifs and couple of other things that might be interesting for Wine.

For remote named pipes, Steve suggested to use mount to set up the pipes, switching from byte mode to message mode and back using chattr. I'll look into writing some example code for Steve to test and then we'll look into kicking that off.

That's it for the monday writeup, I expect that today will give more interesting things to write about.

Day 2

On Tuesday, I had the chance to talk to Sam Ranji from Microsoft at lunch.

He is leading the open source compatibility lab at Microsoft, a lab running only open source software. He told us that he was at SambaXP to figure out how Microsoft could help the Samba community and Samba customers.

The conversation was very polite, but not very much to a point. Sam seems to be pretty reasonable about talking to the open source community, but there is only so much he can do on the Microsoft side. Microsoft seems to acknowledge that there is need for a product like Samba out there and it looks like they have decided to play along. Sam mentioned that there were some bugs in Vista that severely hurt Samba interoperability and that Microsoft fixed them prior to the Vista release.

Simo Sorce then pointed out some cases where Microsoft used to cooperate with Samba and now stopped talking. Dan Shearer told an amusing anecdote about one project manager at Microsoft who wanted to use ports > 1024 for privileged services, and how Tridge wrote a perl script exploiting this potential vulnerability, before it even existed.

Sam seems to be really interested in cooperating with Samba in the area of bug reports, and see where the cooperation can go from there. While this doesn't mean much for Wine, it seems like Microsoft finally is accepting that they can't just will open source software away. We will see how this develops.

----

Centeris is producing Centeris Likewise, a product that supports managing Linux/Unix products using standard Windows administration tools. Centeris' Krishna Ganugapati had a fast-paced talk about Likewise and named a couple of requirements for porting their .NET/Mono based management applications to Linux. Among the things they need are a library similar to netapi32, a library doing DCE/RPC and remote named pipes. Now, if you remember part 1 of my report, remote named pipes is something I already got started on.

Talking to Krishna after his talk, we both realized that cooperating in this area will give Centeris a way to port their product and Wine a way to just thunk to a native library instead of reinventing the wheel. Centeris is happy to fund development in that area and then release this under a free license. I will get into that some more after SoC.

Day 3

The last day of SambaXP was split into two tracks again, one being "case study and vendor report", the other a developer track. I spent most of my time in the developer track, but you might want to check out http://www.sambaxp.org/ in a week or two to see the slides (and listen to the oggs) of some of the case study talks.

A notable talk in the morning was Stefan Metzmacher's talk on active directory replication. Most of the audience seemed to miss the significance of the talk, but personally I think this is one of the important milestones in Samba's history. It's much easier now to move from a Windows PDC to a Samba PDC, as Samba can just grab the active directory via the normal replication routines.

Later that day Lars Müller from the Samba team was talking about uniform Samba binaries as a way to get feedback about fixed bugs without the user having to know about compiling the sources. That might be an interesting idea to keep an eye on, Wine might want something similar once we go 1.0, and I figure that Samba will have something like that set up in 6-18 months.

The most interesting talk on Wednesday was given by Julien Kerihuel from OpenChange. The OpenChange people are building an open source replacement for Exchange. In order to properly support this, they are working on decoding the MAPI protocl, and they also provide a libmapi library for client applications. As a proof of concept, they have an evolution plugin that'll allow evolution to talk to exchange using MAPI. The talk had a couple of demonstrations of the functionality that were greeted with applause from the audience. While OpenChange still has a bumpy road ahead, I'm pretty sure they will manage. OpenChange is the Samba of groupware, definetely a project to watch.

The most exciting talk of the day, at least in my personal biased opinion, was in the case study track. But my perspective on that might be a little off, as that was the talk I was giving. I think it was received well by the audience. It probably won't be too interesting for you folks as you already know what Wine is all about. ;)

The last talk I attended on that day was given by David Holder, who works for Erion, a company that does IPv6 consulting. He had analyzed the Samba source code to check how much work it would be to make Samba IPv6-ready. cifs and Samba4 are almost there, Samba3 needs some work. This is mostly due to the fact that NBT doesn't do IPv6 by design and some of the Samba3 code still is coupled to this.

This is the last installment of this year's SambaXP report. More about Samba from a Wine perspective will certainly follow.

Ivan Leo Puoti has not had much time lately to make the rpms for mandriva. So I volunteered to make them.

So I made a rpm from the latest rpm.

How do I get this rpm on the winehq download server ?

Note that latest Wine RPMS for Mandriva 2007.0 are also available in the official Mandriva main/backports repository.

Updating them to 0.9.35 has been delayed, however, due to an SVN outage at Mandriva.

As Scott Ritchie knows, I'm at the moment the reponsible person for Wine on Ubuntu. I hope that you all know, Ubuntu has a new system for filing crash reports and stacktraces. (named apport aka automatic crash reports, some documentation is found at https://wiki.ubuntu.com/Apport)

Those reports are working quite well for all apps in Ubuntu, but not as expected for Wine, especially when windows apps are involved.

We discussed yesterday about this problem, and now we want your help, to make things better.

What we need from you: what you need from us (Ubuntu) to get better backtraces when wine crashes (especially wine-preloader)

With:

[Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] 1119019818
"Auto"="1"
"Debugger"="winedbg --auto %ld %ld"

in the registry Wine will call winedbg automatically on a crash and get a Win32 aware backtrace.

It would already help to use wine-pthread instead of wine-preloader for generating the backtrace. (Just replace it as traced binary.)

In general the most useful pieces of information are ... complete terminal output, $PWD and the command used to start an application. Also the exact Wine version $(wine --version), and where did it come from (self-compiled or binary). All of them are absent from the report.

Finally we got a Wine booth at Linuxtag 2007 in Berlin. Everybody who wants to participate is welcome. I have to order exhibitor passes, so if anyone you wants to help out please contact me :-)

Well, I was hoping that out of the chatter following my last email, we'd have consensus about the location.

However, the overwhelming silence didn't really help :-/. So, to try to help get some forward momentum, I thought we should turn to a survey again - then we'd just pick the most popular spot.

To that end, if you could visit this page:

http://www.winehq.org/wineconf/survey