Table Of Contents
|1.||14�May�2005�-�20�May�2005||(2 posts)||News: Software Freedom Law Center|
|2.||11�May�2005||(1 post)||Video Capture in Windows|
|3.||11�May�2005||(1 post)||Documentation Moved to SourceForge|
|4.||10�May�2005||(1 post)||Wiki Addition: Debugging|
|5.||8�May�2005||(4 posts)||Flattening Source Directories|
|6.||12�May�2005||(3 posts)||Compiling Problems|
|7.||8�May�2005||(2 posts)||Recruiting Help for Bugzilla|
This is the 274th issue of the Wine Weekly News publication. Its main goal is to fly to LA. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org (http://www.winehq.org)
Mailing List Stats For This Week
We looked at 333 posts in 1288K.
There were 91 different contributors. 51 posted more than once. 55 posted last week too.
The top posters of the week were:
1. News: Software Freedom Law Center
14�May�2005�-�20�May�2005 (2 posts) Archive Link: "News"
People: Eben Moglen,�Alexandre Julliard,�NewsForge,�Slashdot,�Dimi Paun,�News,�ZDNet
We had some pretty big news this week. The Software Freedom Law Center (http://www.softwarefreedom.org) will be providing legal counsel to Wine. The press release (http://biz.yahoo.com/prnews/050511/sfw055.html?.v=9) came out on Wednesday and was quickly picked up in the news media. Slashdot's headline put it well, "Wine Now Has Big-Time Lawyers On Its Side (http://yro.slashdot.org/article.pl?sid=05/05/11/1451234) ". The people behind the SFLC have helped free software for many years, often times silently working behind the scenes to make sure you maintain the right to use free software. An article by NewsForge provided more details (http://trends.newsforge.com/article.pl?sid=05/05/11/1328245) about what the SFLC does and how they can help Wine. Several quotes from Eben Moglen and Alexandre Julliard were included:
"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."
A second bit of news appeared this week about GCC and structured exception handling. Slashdot carried (http://yro.slashdot.org/article.pl?sid=05/05/12/1947213) a story from a ZDNet's Builder UK publication titled, "Wine development stifled by software patent (http://uk.builder.com/programming/unix/0,39026612,39246157,00.htm) ". Wine's Dimi Paun was quoted extensively about the issue. A patch to GCC exists to enable compatible SEH support but can't be included because of a Borland patent. Therefore, Wine can't take advantage of that functionality within the compiler.
2. Video Capture in Windows
11�May�2005 (1 post) Archive Link: "Video capturing under Wine, some overview"
People: Rolf Kalbermatter,�Maarten Lankhorst,�Microsoft
Video capture devices have seen some work lately. This is a new area for Wine so there's been work at trying to figure out how to implement it. The seems to be building on the Video4Linux services. Two folks have been looking at this and coming at it from different angles. Rolf Kalbermatter explained how all this works in Windows and how it could work with Wine:
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\msvid eo 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 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 somwhat 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 provide I haven't found out yet but according to MSDN it should be possible somehow.
For Wine 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.
3. Documentation Moved to SourceForge
11�May�2005 (1 post) Archive Link: "Docs at SourceForge"
People: Dimitrie Paun,�WineHQ,�Dimi Paun,�cvs
Wine's documentation, such as the User Guide and Developers Guide, have been moved into their own CVS repository. Dimi Paun announced:
As most of you already noticed, the SGML docs have moved over to the CVS SourceForge:
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 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.
4. Wiki Addition: Debugging
10�May�2005 (1 post) Archive Link: "New debugging tutorials"
People: Mike Hearn
The new Wine Wiki (http://wiki.winehq.org) saw more new material added this week. Various developers, including Alexandre, put up to do lists. Mike Hearn announced a new page:
I've added the first of what will hopefully become many debugging tutorials to the wiki:
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.
5. Flattening Source Directories
8�May�2005 (4 posts) Archive Link: "Flattening of ddraw directory and renaming of files"
People: Christian Costa,�Mike Hearn,�Alexandre Julliard
Flattening the various DLL directories has come up a few times over the past year. Basically the issue are any of Wine's DLL's that have subdirectories. For example, if you go into dlls/winmm/ you'll see a ton of subdirectories. Christian Costa took a stab at one this week and asked for some feedback:
I plan to flatten the ddraw directory and perform some files renaming in it.
The changes I'm thinking about are in the attached (http://www.winehq.com/hypermail/wine-devel/2005/05/0338.html) file.
If you have suggestions (or objections), let me know.
If this is ok, I plan to submit the changes soon.
Mike Hearn wondered, " No objection, I'm just curious as to the rationale. Why is surface_hal.c? better than surface/hal.c?"
Alexandre thought it would be a good time to do more cleanup, " While you are at it, it would be nice to merge the header files. We really don't need one header for each source file."
6. Compiling Problems
12�May�2005 (3 posts) Archive Link: "CVS compilation problem"
Topics: Build Process
People: Uwe Bonnes,�Alexandre Julliard
I ran into this earlier in the week, you might have too. Uwe Bonnes reported:
I updated yesterday and today. Compiling with todays 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
Alexandre provided the fix:
Do rm dlls/*.def and it should work again.
7. Recruiting Help for Bugzilla
8�May�2005 (2 posts) Archive Link: "Now hiring"
People: Dustin Navea,�Shachar Shemesh
One thing mentioned at WineConf was how we don't respond well to info about problems. For example, there's bugs in Bugzilla that have test cases and patches, but we haven't fixed them. In fact, just going through Bugzilla and cleaning things up can be a lot of work. A few years ago Dustin Navea got involved by doing that. He took a break for a while, but over the past few weeks he's gotten back into it. He asked on wine-devel about getting more people to help:
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..
Shachar Shemesh suggested rephrasing it a bit, " I think "recruiting" is a better term. After all, most armies don't pay salaries worth of anything, and neither do we :-) "
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.