Wine Traffic #313 For 15 May 

By Brian Vincent

Table Of Contents

Introduction

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 (http://www.winehq.org)

Mailing List Stats For This Week

We looked at 381 posts in 793K.

There were 104 different contributors. 64 posted more than once. 62 posted last week too.

The top posters of the week were:

1. News: Wine 0.9.13

28 Apr  - 15 May  (1 post) Archive Link: "News"

Topics: News

People: CodeWeaversMike McCormackRob ShearmanNews

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 (http://prdownloads.sourceforge.net/wine/wine-0.9.13.tar.bz2) 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.

2. GPhoto / TWAIN Integration

1 May  (1 post) Archive Link: "PATCH: [0/4] Splitting TWAIN_32 and adding gphoto driver"

Topics: Integration

People: Marcus Meissner

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:

Drivers:

Autodetection:

The code is ready for WINE inclusion (tm).

Three days later Marcus posted another patch with some minor changes.

3. Dynamic Drive Configuration

11 May  - 12 May  (3 posts) Archive Link: "[0.9.13]Dynamic drive configuration using HAL?"

Topics: Filesystems

People: Mike HearnAlexandre JulliardUwe Bonnes

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 ;-)"

4. Mail / News Gateway & Support Revamp

(70 posts) Archive Link: "Support section revamp`"

Topics: WineHQ

People: Jeremy WhiteWineHQGoogleMarcus Meissner

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 (http://www.winehq.org/mailman/listinfo/wine-users) mailing list was a gateway to the comp.emulators.ms-windows.wine (http://groups.google.com/group/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:

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:

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 (http://www.winehq.org) 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.

5. Testing Wine's Audio

7 May  - 9 May  (4 posts) Archive Link: "A great way for non programmers to help with Wine - Audio"

Topics: Multimedia

People: Jeremy WhiteCodeWeaversRobert ReifGoogle

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:

Sound report:

Results:

Results can either be sent to [email protected] or perhaps even to Jeremy directly (Google should provide his email at CodeWeavers.)

6. Rendering HTML

1 May  (3 posts) Archive Link: "shdocvw 2: Added [get|put]_Visible implementation."

Topics: Web/HTML

People: Jacek CabanMicrosoftDimi Paun

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 (http://wiki.winehq.org/ShDocVw) .

Because AFAIK there is much interest in Steam, I plan to do the switch as follows:

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.

7. ITypeInfo_fnInvoke

2 May  (5 posts) Archive Link: "Anyone actively working on ITypeInfo_fnInvoke and VariantChangeType?"

Topics: RPC / COM / OLE

People: Bill MedlandRob ShearmanTony LambregtsAlex Villacis Lasso

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 (http://bugs.winehq.org/show_bug.cgi?id=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.

8. WaitCommEvent Deadlock

9 May  - 12 May  (5 posts) Archive Link: "[Wine] Wine + serial port basically hangs system"

Topics: IO

People: Uwe BonnesEric Pouech

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:

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.

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.

9. Linuxtag Attendance

2 May  (1 post) Archive Link: "Linuxtag06/Wiesbaden/Germany"

People: Uwe Bonnes

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.

 

 

 

 

 

 

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.