Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #271 For 22 Apr 2005

By Brian Vincent

Table Of Contents


This is the 271th issue of the Wine Weekly News publication. Its main goal is to buy a car. 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

Mailing List Stats For This Week

We looked at 115 posts in 592K.

There were 55 different contributors. 23 posted more than once. 29 posted last week too.

The top posters of the week were:

1. News: WineConf

18 Apr 2005 (2 posts) Archive Link: "News"

Topics: News

People: WineHQNews

Let's see..

WineConf 2005 is next weekend in Stuttgart and most of the plans are in place. For those of you not attending, there will likely be a bunch of people at the conference hanging out in IRC ( on #winehackers. We will not have streaming audio or video this year. We failed miserably at it last year and it really seemed to take up a lot of time at the conference. Of course, if someone shows up at WineConf with a killer streaming audio system that's reliable we'll probably use it. For any last minute details like that, keep an eye on wine-devel or maybe even WineHQ.

This is also the cue that there probably won't be an issue of WWN next week.

2. MSHTML & Gecko

17 Apr 2005 - 18 Apr 2005 (3 posts) Archive Link: "Enabling Gecko in MSHTML"

Topics: Integration

People: Jacek CabanIvan Leo Puoti

Jacek Caban announced more details on his work implementing MSHTML. He had a large patch included with his email:

Now MSHTML is ready for a patch that enables HTML rendering over Gecko API. I attached the patch that makes IE works with Wine's MSHTML. Any comments/suggestions are welcome. If you want to see how it works, you need to have a working installation of IE and Mozilla installed under Wine. Then just set mshtml.dll to be loaded as built in. Excluding many not implemented parts of API, it needs a better algorithm searching for Mozilla installation (eg. currently it can't work with only Mozilla ActiveX Control installed) and better messaging user that it needs Mozilla, but I'll fix it in next patches.

I'm not sure if I should presently send it to wine-patches. I still hope we can make it work with Linux versions of Mozilla. It would be much better as applications could 'just run' for users that have Linux Mozilla installed (and most have), without any additional installation/downloading . I tried to do it, but without success as yet. Problem is that we need to pass a native window handle to nsIBaseWindow::InitWindow (you may see this call in view.c). In case of windows version it's no problem as it means passing HWND, but in case of Linux it is Gtk/GdkWindow (well, not always as Mozilla can be built to use xlib or qt, but currently in most cases it's not and we can take care of it later). To not use gtk/gdk directly in Wine we could patch Mozilla to detect XID passed and use gdk_window_foreign_new to create GdkWindow. It should work, I believe, but I was not able to do so. It would be wonderful if anyone could give me any insight on it, eg. I'm not sure if I have a good understanding of how to get the XID for Wine's window. Also I'd like to know if using gdk inside Wine's windows needs any tricks/is possible. If you think I should give up and stay with the Windows version, I'll send this patch to wine-patches.

Ivan Leo Puoti wanted to know if it would work with a native Linux Gecko (e.g. Mozilla). Jacek thought it would, but asked if anyone could help with it:

Yes, I believe. Unfortunatelly I've not succeeded in this as my knowlage about X and gtk programing is poor. So I need some help on it. A patch that makes nonwindow-like stuff to enable UNIX Gecko is attached. To make it complete, 'just' one error in view.c has to be fixed.

As it's the development version, path to Mozilla dir is hardcoded - it'll be simple to fix, but first I'd like to see it working. To make changes more clear, this patch depends on my last patch I've sent yesterday. Parts of code that depend on version of Gecko used are ifdef-ed by UNIX_GECKO.

Any help/suggestions very welcomed.

3. Webcams with Wine

17 Apr 2005 - 20 Apr 2005 (3 posts) Archive Link: "VfwCapture question (and attached a v4l2 patch for msn 6.2 webcam - Attempt 1)"

Topics: Integration

People: Maarten Lankhorst

Maarten Lankhorst sent two message this week with patches outlining work he's done to get webcams to work:

SInce stuff is missing from msvideo (ICSeqCompressFrame{Start,,Stop}) you have to use native MSVFW32.DLL

This will crash when you stop msn webcam (Because of the CreateThread continuing to run) In general it is very unstable, but at least it proves you can use 'webcam's under wine.

How does it work? apply patch set quartz, qcap and devenum to builtin (qcap just to be sure..) set msvfw32 to native (and make sure you have a native msvfw32) regsvr32 quartz.dll Run msn messenger (I tested it with MSN 6.2, dutch version, not sure wether it will work under 7.0) Now you can use the 'webcam'

If you want, you can even make some patterns by changing the following lines in capture.c ;)

This patch is not very stable yet, but it's still a work in progress.. If anyone got some links to gstreamer tutorials that would help me with this, I would happily accept :)

The second email described further work:

Now that I'm pretty much done with cleaning up the stuff, I'm wondering on how to seperate /dev/video0 from /dev/video1, in the current code I don't have the seperation, and I'm unsure on how to add it...

Anyway, this is my first attempt to get v4l2 to work with msn 6.2, it is very unstable but it somehow.. works.. to transmit images over the web though, here's what the patch does:

Currently it requires a video4linux2 device for the vfwcapture interface, but since the bttv driver supports v4l1 too, I'll work on it. The code will crash when transmission is halted (because of the testbed thread not being stopped), but I thought I would add this so you would know I'm still working on it :). to compile the code, make sure you have /usr/include/linux/videodev{,2}.h and then compile with make CC="gcc -DENABLE_V4L" Don't expect to much from it.. oh and you need to use the native msvfw32.dll to native to transmit images.. you can probably steal it from a windows installation or download it from dll-files... I made a screenshot of the preview screen at - It actually transmitted too, frame counter was at 7846 until it crashed (Destroying VfwCapture, TestBed thread crashed)

But if you really want to help, can someone _*PLEASE*_ figure out why it crashes if it's started with WINEDEBUG=+quartz and when you go to webcam settings screen? you can save me a lot of frustration.. thanks!!!

4. USB Support (con't)

18 Apr 2005 (2 posts) Archive Link: "USB status ..."

Topics: IO

People: Damjan JovanovicHijiLars Segerlund

Last week (WWN #270 we covered a thread concerning USB and Wine. Damjan Jovanovic seems to have put a lot of thought into this and he described it:

I have proposed several possible solutions for using USB under Linux. In fact, I have given 4 possible ways of doing it, one of which I have hacked up (and gotten to work, at least partially).

If you're interested in the details, let me know, and I'll email you (or look at the "Wine device drivers proposal" email in the Wine archives in the past month or so).

Briefly, Windows apps never use USB directly (there is no equivalent of libusb on Windows; well there is libusb-win32, but no closed-source projects use it). They open a "device file" of the form \\Device\Options; so for instance my scanner driver opens \\MiiScan0 and \\MiiScan0\0\0\2. This opening is done using CreateFile(), which returns a handle.

3 other important functions are then used:

Windows 2000 and XP have a set interface for using scanners, for example, so the parameters to these functions would be well known. For most other hardware it is trivial to reverse engineer it if necessary.

The problem is, Wine does all I/O (ie. ReadFile(), WriteFile(), DeviceIoControl()) using the @&#$!"* wineserver, by querying the wineserver for a file descriptor (int obtained by the POSIX open() function in Linux), and then doing read() or write(), while DeviceIoControl() in wine delegates to CDROM_DeviceIoControl() or fails.

CreateFile() is reasonably easy to hack - but the problem is that you need ways to:

  1. Associate particular file descriptors to a dynamically linked library that would be identified by the CreateFile() argument (eg. for \\MiiScan0\, maybe the library would be
  2. Load up the library on CreateFile() with a reference count of 1 and unload it when CloseHandle() decrements the reference count to 0.
  3. Use the library's functions for reading, writing, and ioctl's.
  4. (This is the hardest part) Make ReadFile(), WriteFile() and DeviceIoControl() aware of which file descriptor identifies which library, and call the right libraries functions. This probably requires changes to the wineserver.

Phew, I thought I'd type a short reply! Interested in working on this? I can't do it all alone.

Hiji thought between Damjan and Lars Segerlund there might be an opportunity to develop something:

There's not much I can do other then try to encourage you and Lars to work together (as I'm not a C developer). Damjan, it sounds like you have already covered a lot of the groundwork through your research and understanding of the USB infrastructure (from both the Windows, Linux and Wine worlds). Lars, I see you have both the motivation and experience with Linux device drivers to work on Wine USB.

To me, it sounds like a perfect match for you two to pair up and work on implementing additional USB functionality.

I suppose the last piece missing is to consult the expert on the wineserver (as far as USB is concerned) to see if any changes would truely need to be made there. Who would that be?

5. DirectX 9 - Merges?

20 Apr 2005 - 21 Apr 2005 (4 posts) Archive Link: "D3D9 Work?"

Topics: DirectX

People: Benjamin CutlerJesse AllenJason EdmeadesOliver StieberWineHQJasoncvs

So Oliver Stieber's DirectX 9 haven't been merged into WineHQ and some folks are a little anxious to get it in. It seems other DirectX work is waiting on that. It led Benjamin Cutler to ask:

I was discussing this with some others who hang out in the #winehackers channel, and I'm curious who else might be working on the D3D9 portion of Wine. I was unsure of how ready for inclusion into the main branch the unofficial patches are, but I've heard from a couple sources that most of the patch isn't. I'd like to get some opinions on what's ready and what's not. I'd hate to start submitting pieces of the patch, only to find out that person X was already working on that part and had something better in mind, or even worse to find out that somebody's been maintaining contact with Oliver and I'm just getting overeager to see the patches in Wine.

Somebody also mentioned that there are others waiting for Oliver's patches to be submitted so that they can continue their D3D9 work, so I was curious if there were any of you out there that fall into that category.

At present, the best I can really do to contribute is help keep the branch synced up with the current CVS (migrating the 20050310 patch to 20050419 resulted in a lot of conflicts that took me most of the night to work through), but given some time I could probably learn enough about DX9 to get a better handle on how things are supposed to work and start making more solid contributions. That will probably have to wait until late May, however, once this college year ends.

He didn't hear anything back, so the next day he worked on it and reported:

I spent most of the night trying to merge the old 20050310 patch into the 20050419 release, and I came up with the diff linked below. Keep in mind that I only attempted to get it to compile, I did not attempt to make sure it was stable or correct. For what it's worth, I *was* able to get my test games to launch and they ran pretty much exactly as they did with the old patches, but that's no guarantee of anything.

Oliver seems to be MIA. His home page has disappeared and nobody I've asked has been able to successfully contact him. If somebody wants to clean this up and merge it back into the main WINE tree, please do, because I don't know enough about DX9 to even think of attempting such an undertaking myself.

Of course, I'll feel rather foolish if Oliver pops up tomorrow and has a real patch, but here's what I can offer for now.

Jesse Allen thought some work could be done on it, " Well at minimal, you can submit small bug-fix patches to try to avoid duplicate work. I've been testing D3D9 and I know for sure there are bugs out there. There may be some in Oliver's patch, and I'm sure he'd appreciate the help when he gets back. So in case there is some other work going on, just keep testing a little what we got and we can make the life easier for someone that knows more and can spend time on it."

Jason Edmeades, who started the recent DirectX 9 push, replied as well:

FYI I stopped d3d9/wined3d work when I got to a point I had completed the parts I was doing, and Oliver had sped ahead so I was ending up duplicating work he was doing - I've put it to one side while waiting on the cvs tree to get up to where he was.

The last I heard, Raphael was also willing to look into the shader side of things, and had an outstanding patch for hardware vertex buffer objects to help performance, but I think again this was waiting on Oliver's commits.

However, if there seems to be problems, I don't mind continuing, or helping people work through his patch into manageable chunks for submission - I can easily give guidance in this area.

I have only limited time, and work a patch at a time, until it gets in cvs, because as is the case with his current patch, basically it needs reworking into submittable chunks! However, I think we should give Oliver a little more time (I wont be touching it until after wineconf anyway).

Not knowing anthing about d3d8/9 shouldn't hold you back - I knew nothing when I started on the d3d8 stuff, and it doesn't take that long to pick up the threads.

FWIW I tried applying the patch sent on here the other day and it failed to compile (WINED3DFORMAT vs D3DFORMAT), but after fixing that, I tried running a simple textured demo and it failed (Tutorial 5 from - Any chance you could see if it works for you and if it does send me (offline) a patch for current cvs?

6. Wine DLL's on Windows

16 Apr 2005 - 18 Apr 2005 (4 posts) Archive Link: "Still more fun?"

Topics: Integration

People: Jakob ErikssonSteven EdwardsRolf KalbermatterMicrosoftReactOS

Jakob Eriksson wanted to know if anyone had used Wine's DLL's on Windows:

Has anybody else thought of using DLLs (like ReactOS' dlls) as a compatibility layer to different Windows versions? I.e. when you distribute your Windows app, you also throw in a bunch of DLLs that implement lots of functionality you aren't sure exists on your target otherwise. (Windows 2003 functionality on Windows XP, 2000 and NT for instance.)

It would be a way to avoid upgrading Windows. This would be good for developers, users and the Open Source community. The longer it takes for Microsoft to shove out a new version of their OS, the more time Open Source has to infiltrate. :-)

I first had the idea when a program of mine refused to run on Windows 95 when it was compiled with Visual C++ .NET. It "needed" some XP functionality in a DLL not present on Windows 95. Well, I created a dll with the same name and distributed it with my program.

Steven Edwards explained a way to do it, albeit for a different reason, " I think it would be good in testing Wine/ReactOS vs Windows for Winelib applications developers. You can make a dummy file in your application directory called application.exe.local to force Windows to use the dlls in the local directory. So say you have IEXPLORE.EXE you would create IEXPLORE.EXE.LOCAL and drop the Mingw compiled dlls in to the application folder and see how it runs."

It led Rolf Kalbermatter to ask:

Why would you need the .local file? Has there anything changed in XP or 2003 which would prefer Windows or system DLLs over local DLLs in the same directory as the calling executable?

I always was under the impression that the executable directory was the first to be searched by LoadLibrary() for a DLL and it has worked that way for me in the past, too.

Steven explained:

The behavior of LoadLibrary has changed at least once that I know of for Windows 2003. The default search order can be set per application in the registry as well. Microsoft even does the programname.exe.local trick with the IE5 setup wizard. Extract the IE5 wizard in to a temp folder and lauch IE5 setup and you will see the *.exe.local file. iTunes even does it.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.