World Wine News

"We will have a very strong portfolio of crucial components that make up the FOSS enterprise software stack, including operating system components and crucial application layer products," Moglen said of SFLC's free legal assistance recipients, more of whom will be announced in the next four to six months. These projects will be joining the Free Software Foundation, Samba Project, and now Wine, which already receive SFLC services. Headed by Moglen, the center also boasts the open source legal expertise of well-known attorneys Diane Peters, Lawrence Lessig, and Dan Ravicher.

Moglen said Wine was a logical client for the center because it represents a pillar of interoperability -- something the SFLC uses in its argument and crusade for free and open source software and open standards.

"Wine is crucial to our interoperability portfolio," he said. "It allows businesses to take their Windows legacy applications with them. The legal usability of Wine is integrated into our interoperability case because of the fact that it incorporates Windows APIs. The Software Freedom Law Center wants to be sure our premier interoperability tools are tools we can use with confidence. This strikes an important step, securing our case that FOSS is fully interoperable."

Prompted by the recent work by Maarten Lankhorst on getting his video cam to work in Wine, I did some in depth investigations on how Windows actually does this stuff.

This is a summary of what I found and some thoughts about it. I would like some comments on how to progress.

Basically applications have two obvious ways to use video capture services in Windows. One is avicap32.dll which is basically the Video for Windows way of doing this and the other one is ActiveMovie/DirectShow, soon to be obsoleted by Microsoft as well, as it seems.

Avicap32 implements two functions, one is for the enumeration of the VfW devices registered in the system. For this it does enumerate all entries in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MediaResources\msvideo and for compatibilty reasons with 16bit Windows also in the Drivers32 section in system.ini. I have an untested version of this code already. The enumeration function does not try to detect any devices other than what it finds in the above mentioned places. I assume that a webcam driver installation would have to do that. The second function in Avicap32.dll creates a (hidden) window which handles the actual interaction with the video device as well as being an optional user interface for the video data. The communication with the video device is always by so called installable drivers, like wineoss, etc. is used for audio devices. The interface to these installable video drivers is for the video device specific parts declared in a header file msviddrv.h which is really part of the DDK. (How would we add that to the Wine headers?) In modern Windows systems there is one MS provided installable driver vfwwdm32.dll, which is basically a translation layer between the installable interface and modern WDM stream based video drivers.

Devenum uses the avicap enumeration function to find all registered VfW video sources and provide them to an application. Presumably there are other possible video source objects which would provide a direct interface to WDM stream class devices somehow and could be enumerated by devenum as well.

DirectShow seems to be somewhat complicated. Video sources can be provided from VfW again, which is provided by the "VfW Capture Filter" class in qcap.dll. This is basically a DirectShow filter wrapper around the same installable driver interface as is used in avicap32.dll (and through above mentioned vfwwdm32.dll driver an application can also access WDM stream class video capture sources indirectly. How the direct interface to WDM stream class devices is provided I haven't found out yet but according to MSDN it should be possible somehow.

For Wine's purposes the VfW path seems the most interesting one. Separating the Video4Linux interface into an installable multimedia driver such as winev4l would cleanly separate platform specific code from the rest of the Wine DirectShow and Avicap implementation. Trying to emulate direct access to WDM based drivers would not be possible anyhow, as that would seem to require kernel driver support, which is mostly absent in Wine.

I could probably hack an experimental winev4l driver together based on the work already done by Maarten Lankhorst, but would first want to make sure that this is considered the way to go, before investing more time into this. While the current implementation by Maarten is not as clean and nice because of the direct V4L dependency in standard Wine DLLs, it is something which already works somehow and could be integrated into Wine in quite a short time.

As most of you already noticed, the SGML docs have moved over to the CVS SourceForge:

http://sourceforge.net/cvs/?group_id=6241

They clearly did not belong in the tree, and we decided at WineConf05 to move them out of there. So we did.

I have renamed the files for a more uniform naming, and dropped a couple of unused files in the process. We still need to change WineHQ's scripts to point them to the new location. Help with this would be appreciated.

I'll be managing that tree for now (unless Alexandre wants to do it :)). Please send your patches as you usually do to wine-patches_at_winehq.org, but make sure to prefix the subject with '[WINEDOCS]' so I can more easily spot them. Discussions should take place on wine-devel_at_winehq.org as per normal.

The new repository is set up with translations in mind, so hopefully will be able to handle them better in the future. I'll be working with Francois to integrate the French translation shortly.

I've added the first of what will hopefully become many debugging tutorials to the wiki:

https://wiki.winehq.com/DebuggingTutorials

Sometimes fixing Wine can be a bit hard to get into. Hopefully these short "show me" guides will give people a taste for what it involves and help newbies start.

Please feel free to add more! They shouldn't be too advanced (so no copy protection, WM or DCOM debugging ;) but multiple levels of difficulty is fine. Ideally they should all be based on real apps.

I plan to flatten the ddraw directory and perform some files renaming in it.

The changes I'm thinking about are in the attached file.

If you have suggestions (or objections), let me know.

If this is ok, I plan to submit the changes soon.

1. This removes the directories hierarchy (which is not really necessary)
2. You don't have several files with the same name (there are 6 main.c, 3 hal.c,... and when they are all opened for editing, this begins to be a little confusing)

I updated yesterday and today. Compiling with today's CVS gives:

../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole
joystick.o keyboard.o mouse.o testlist.o -o dinput_test.exe.so
-L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/dinput
-L../../../dlls/ole32 -L../../../dlls/version -L../../../dlls/user32
-L../../../dlls/kernel32 -L../../../libs -ldinput -lole32 -lversion -luser32 -lkernel32 -ldxguid -luuid -ldxerr8
joystick.o(.text+0x543): In function `EnumJoysticks': /spare/bon/wine-realclean/wine/dlls/dinput/tests/joystick.c:165: undefined reference to `c_dfDIJoystick' joystick.o(.text+0x592):/spare/bon/wine-realclean/wine/dlls/dinput/tests/joystick.c:169: undefined reference to `c_dfDIJoystick2'
collect2: ld returned 1 exit status

Do rm dlls/*.def and it should work again.

It seems we have run low on "official" janitors, I have talked with someone that seems to know what they are doing as far as the right way to bug report (he contribs to MPlayer), and he said he would be willing to help maintain bugzilla, but that he doesn't have a whole lot of time, the extra hand will be helpful. Could you add 'canconfirm' and 'editbugs' to inverseparadox_at_comcast.net?

Does anyone have any objection to me posting a note on wine-users that we are accepting applications for dedicated bug maintainers (read: janitors lol)?

I will handle "interviewing and hiring", and just send an email to Jeremy when we get people that know what they are doing and can really be of use.. I think 5 should be good for now..