This is the 313th issue of the Wine Weekly News publication. Its main goal is to sit on a lake in Montana. 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
The past few weeks have been a little slow in the world of Wine. Alexandre went on a 2 week vacation and no new patches were committed to the main git repository. Interestingly, in his abscence Mike McCormack began committing some of the patches from wine-patches to his git repository and updated everyone on what it contained. In this respect it allowed something we've never had in Alexandre's abscence - a maintained patchset others could access. It seems to have paid off. Upon Alexandre's return he began updating the main tree and quickly released Wine 0.9.13. Noted additions included:
Go download it.
We haven't really talked much about the whole RPC/COM/OLE world lately. Mostly because most of the work is being done by Rob Shearman and hasn't generated much discussion on wine-devel. (And that's mostly because there's about a dozen people in the world who understand the nuances.) Anyway, the effort seems focused on CodeWeavers work to get Outlook 2003 to work out of the box with Wine's DCOM. As usual, there will likely be collateral damage that gets other apps working better. There's a small thread below illustrating that.
As far as WWN goes, expect a few more erratic updates as I'm traveling.
We mentioned a few weeks ago Marcus Meissner had started working on getting digital cameras to be usable in Wine as a TWAIN data source. Using gphoto, it should be possible to access images directly off the camera using a Windows application. There was a bit of discussion concerning how to organize everything and Marcus described the final implementation:
This series of patches splits up the sane specific parts of twain_32 into the controller part (twain_32) and sane specific driver part (sane.ds). It also implements a working gphoto driver (gphoto.ds).
TWAIN itself has a concept of:
- DSM / Data Source Manager ... A controller that manages the datasources and their lifetimes.
This was and is still found in twain_32.dll- DS / Data Source(s) ... A multitude of datasources, usually per camera / scanner drivers found in %windir%/TWAIN_32/ and subdirs.
Up to now this was also in twain_32.dll, but this series splits it out.Drivers:
- sane.ds: The old twain_32.dll sane code split off from twain_32.dll.
- gphoto.ds: New gphoto importer code, originating from the old sane.ds as example.
Autodetection:
- Autodetection has been moved from twain_32.dll to the drivers.
- twain_32.dll itself is no longer dependend on libsane and actually has only minimal knowledge of sane and gphoto2 (the driver names ;)
- Detection of multiple devices is in the DG_CONTROL/DAT_IDENTITY/MSG_GET calls of sane.ds and gphoto2.ds. A little hidden channel detects multiple scanners / cameras by calling above function multiple times.
The code is ready for WINE inclusion (tm).
Three days later Marcus posted another patch with some minor changes.
The latest Wine release had a note about dynamic drive configuration.
That led Uwe Bonnes to ask what it was all about since it was one of
those little things Alexandre added without any explanation on wine-devel.
Mike Hearn replied first,
My guess from reading the code is that whilst Wine is running, any HAL
hotplug events will be magically handled correctly. For instance, run
Notepad, look at the file open dialog box. Close it, plug in a USB key,
and do File->Open again. You should see a drive letter corresponding to
the key.
Alexandre explained it's a little more than that,
Yes, it's all magic. If you run winefile you should even see the new
drives appear and disappear as the devices are mounted/unmounted. Note
that it requires pretty recent versions of the kernel and of the HAL
libraries. There are a lot of broken setups out there, so if it
doesn't work for you it's not my fault ;-)
This little bit of news occurred a few weeks ago but I forgot to report on it. A long, long, long time ago the wine-users mailing list was a gateway to the comp.emulators.ms-windows.wine newsgroup. When we switched to using mailman for the mailing list things broke. A lot of people were dismayed by that and both the mailing list and the newsgroup suffered as a result.
Well, last month there was a huge discussion regarding adding a web forum to WineHQ. Frankly, everyone seemed to agree that we just don't have the resources to support such a thing. There was also a huge argument regarding web forums in general. Some people thought web forums were annoying while others thought they're simply The Best Thing In The World. I'm not going to really cover that discussion since it tended to ramble. Part of that discussion also brought up the fact we've done a poor job presenting support options available. Marcus Meissner came up with an acceptable solution for the forum part of it and Jeremy White expanded on that with what eventually became reality:
Okay, so I've followed this thread, and I have a range of thoughts and what I think is a simple solution.
First of all, if disk space is an issue, it's easily corrected with a $100 IDE drive. I think the real issue is that Jer doesn't like to work on half baked ideas unless they're more fully baked or someone else he trusts is cooking in the kitchen :-/.
Second of all, it seems to me that the biggest problem is simply one of presentation. This is the relevant page:
http://www.winehq.org/site/forums
The current information is really quite poorly presented. There is way too much information; the useful bits (the Gmane and Google links) are buried way to deep imho.
Third, I think the biggest problem is that there are 2 places to go for help. The wine-users mailing list, and the legacy usenet newsgroup.
For a while, the two were connected, until the old gateway we were using broke down, and Jer ripped his hair out trying to make it work.
But time has passed, and now Mailman has a builtin news <--> mail gateway system, and maybe we can reconnect them. (I'll go discuss this with Jer; if I'm not heard from ever again, it's because he beat me to a pulp with his printout of the Mailman manuals <grin>).
But if we can reconnect them, then I think a nice solution would be to retool that page so the Google interface pops out:
http://groups.google.com/group/comp.emulators.ms-windows.wine
That looks forumishy enough to me to satisfy many people, and yet is nicely backwards compatible with all current systems.
If you go to WineHQ you'll notice all of those changes have now been made. Users of the newsgroup probably noticed a large spike in traffic as a result.
Jeremy White sent an email to wine-devel asking for help in testing Wine's audio implementation. This is great task for non-programmers. Given that there weren't any public replies, it seems like help is still needed:
I've taken the liberty of changing the subject of Robert Reif's recent email and am expanding it a bit, because I don't want it to be ignored.
The task is to perform a basic test of Wine's audio support to make sure it's a stable platform for us to build upon; what a great way for all you lurkers to help us out <wicked grin>.
The basic procedure is - get a current version of Wine, test the sound, and send the results in. It won't take long (took me ~30 minutes), and it'll be very helpful.
More details:
- Checkout Wine from CVS or git
- Figure out if you're using OSS, Alsa, or Alsa in OSS emulation mode (lsmod is your friend, and winecfg is quite nice as well)
- Run the test:
- cd dlls/winmm/tests
- WINETEST_INTERACTIVE=1 wine winmm_test.exe.so wave 2>&1 | tee /tmp/wave.out
- important: As it runs, you should hear a nice steady set of soothing beeps, all at the same pitch and duration. If you hear any variation from that, make a note of it, so you can report it. It's important to listen the whole way through; a tad boring, I know, but important; it'll shift to a virtual device half way through and it's important to hear if it keeps on working or not.
- Report your results: Pack up your output files, and report your results along with your sound driver info. Failures are obviously the most interesting, but success on not previously validated hardware/driver combos are likely to be useful too.
Sound report:
- Kernel 2.6.13
- Sound driver: snd_intel8x0
- Sound driver description from lspci:
Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)- 32 bit Debian system
- Alsa version 1.0.10-2
- Tested against Wine CVS up to date as of 5/7/06, 10:27 (without Robert's last two patches :-/; folks might want to wait a hair until those are applied)
Results:
- Tested under winealsa, as well as wineoss with OSS emulation
- All sounds played flawlessly. Alsa runs reported 0 failures. OSS runs reported 48 failures; not clear if that was relevant
- Only anomaly is that the modem driver is treated as an OSS sound card, and so has a number of flawed attempts to play against it
- Full log files of the runs attached.
Results can either be sent to wine-devel@winehq.org or perhaps even to Jeremy directly (Google should provide his email at CodeWeavers.)
There's been a huge effort over the past year and half to write our own version of Internet Explorer. Now, IE itself is really just a wrapper around a couple of big libraries. You might remember the big thing several years ago when Microsoft "integrated" the browser with its operating systems. The value, they argued, is that other applications could just use those API's to become web enabled. Well, it happened and it has been a problem for programs running under Wine that need to access those API's. It was somewhat stemmed by using the Mozilla ActiveX control. However, it's really necessary to have our own since the ActiveX control has proven to be problematic.
Fortunately, there exists a wonderful HTML rendering engine in Mozilla. So Jacek Caban took to the task of building out those API's using that as the backend. The real switch will come when our MSHTML library switches over to the code he's been submitting. That led Dimi Paun to ask if it will be better than the current method. Jacek replied:
Well, IMO it is better now, but it depends on criterion. Mozilla ActiveX control has more functionality implemented, but their compatibility with native WebBrowser is quite bad. They seem to believe MSDN... Everything I wrote was tested and compared to windows version so our compatibility should be quite good. Also we have the correct architecture while Mozilla doesn't. For someone not interested in insides of those libraries probably the more important thing is what and how works. After the switch to our implementation bugs 3466 and 3515 will be fixed. In both cases there are still some problems, but apps can run and view HTML.
If someone wants to test it, I've created a Wiki page about it: http://wiki.winehq.org/ShDocVw.
Because AFAIK there is much interest in Steam, I plan to do the switch as follows:
- Make Steam work perfectly (I mean its HTML part)
- Do some testing and improvements to prevent regressions
- Finally get rid of Mozilla ActiveX control dependency
But it will have to wait until I pass my exams...
If you follow Jacek's link you'll see the steps to perform to test out the new code. If you've tried to use the ActiveX control in the past and it hasn't worked, you might want to try out the new stuff.
If you're looking to hack on Wine and want a project, one possibility would be to flesh out our IE program that was recently committed. Currently the iexplore.exe program is a simple window lacking the typical web browser controls. Fleshing out the program would involve implementing all the wonderful navigation features of a browser using the new API's.
More and more work on Wine's OLE / COM infrastructure has led to a lot more programs working out of the box. Bill Medland wrote in this week with a specific question concerning a custom app:
Anyone actively working on ITypeInfo_fnInvoke and VariantChangeType? (before I start trying to get up to speed on it.)
Congratulations. My company's program now gets somewhere with the builtin ole dlls (thanks to fixes in the out-of-process COM) so I am interested in trying to get it to work completely with them (especially since the native ones no longer work)
What I have just fallen over is some VB that calls a method that results in ITypeInfo_fnInvoke failed to convert param 0 to VT_VARIANT| VT_BYREF from VT_I2.
So I changed the VB and ended up with ITypeInfo_fnInvoke failed to convert param 0 to VT_VARIANT| VT_BYREF from VT_VARIANT|VT_BYREF.
Now it seems to me that it ought at least to handle the second case, but that probably demonstrates that I don't know what I am talking about.
Anyway, if someone is already working on that sort of thing then there is probably little point in me trying to learn it all. However if no-one is then I guess I will start trying to learn it.
Tony Lambregts and Alex Villacis Lasso both replied that the bug sounded exactly like one in Bugzilla, #4370. Rob Shearman, Wine's resident COM guru, posted a patch and asked for feedback:
I had hoped others would continue development on typelib stuff, picking up from where I left off after the rewrite to use more of VariantChangeType, but unfortunately this isn't the case and I don't have enough time to work on this area too much. Fortunately, I don't think there are too many issues left to fix and already the new code in ITypeInfo::Invoke gets some programs working that wouldn't work with the old code.
Does this patch fix both issues for you?
Bill reported success and asked that Rob submit the patch for inclusion.
Uwe Bonnes brought up a problem with some code he wrote a while ago:
this is a thread from wine-users. I think further discussion of this issue is better done on wine-devel.
In short, Dan Armbrust notices some application (heavy weather.exe) accessing the serial port causing a high system load. As the application uses WaitCommEvent, I fear that my implementation of WaitCommEvent is inappropriate. In my last posting, I ask Dan to count the calls to WaitcommEvent by counting the number of lines containing WaitCommEvent in a relay log. His results are:
I let the app run for about 2 minutes, at the standard priority - basically until the system was about ready to take a dive :)
As Dan's machine is not a "big iron one", I guess these about 7500 thread creation/termination in about 90 seconds could explain the high system load.
Data was coming in to the program and being displayed before I killed it.
The count on WaitCommEvent was 15051 - so I guess we would have 7526 calls to WaitCommEvent in < 2 minutes. It probably took the first 30 seconds just to get the app up and running, so that was maybe 90 seconds of actually accessing the serial port.In the moment, my implementation of WaitCommEvent creates a thread in the context of the running program for every call. Any ideas how to do it better?
Eric Pouech suggested:
the preferred way is of course to do the wait operation in the server (or at least the trigger in the server, and the handling of the trigger can be done on client side)
Uwe felt that was outside of what he could tackle, so for now there may be an issue with apps that make a lot of calls to WaitCommEvent. Ron Jensen then mentioned that there appeared to be a related bug that crept in recently when some code was moved between kernel32 and ntdll. Eric recognized the issue and submitted a patch.
Uwe Bonnes let everyone know Wine would be represented at Linuxtag:
Stefan Maunz, Micheal Jung and me will present Wine at Linuxtag06 in Wiesbaden, Germany.
As a project we can send out invitations. If anybody is interested to receive an invitation, please let me know.