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 #312 For 28 Apr 

By Brian Vincent

Table Of Contents


This is the 312th issue of the Wine Weekly News publication. Its main goal is to attend weddings. 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 614 posts in 1184K.

There were 134 different contributors. 88 posted more than once. 51 posted last week too.

The top posters of the week were:

1. News: Ulrich Czekalla, CrossOver Review

11 Apr  - 28 Apr  (3 posts) Archive Link: "News"

Topics: News

People: Ulrich CzekallaCodeWeaversLinuxWorldNewsforgeMicrosoftNewsVersora

Wine's Ulrich Czekalla presented at the Toronto LinuxWorld Conference & Expo this week. Newsforge was on hand to cover the event and they have a detailed report of it. Ulrich outlined the current state of Wine and where development is headed:

Where is Wine going? There are some messy areas, says Czekalla. One of these is its Component Object Model (COM) implementation. After years of work, it is still not done and is at least six months away from being able to talk to a Microsoft Exchange server.

Right now about 70% of programs can install with Wine's implementation of the Microsoft Installer (msi.dll) library. In another year, Czekalla expects that number to be about 90%, though he pointed out that while most programs that install will work after being installed, there is no guarantee. One problem Wine has had is with the device-independent bitmap (DIB) engine. At the moment it supports only 24-bit color depth graphics, but many Windows programs still use only 16 bits. He described this as a problem with X.

Because Wine is a userspace program, and cannot see hardware, things such as USB devices (like a USB key) cannot be directly seen by programs running under Wine. An effect of this, he says, is that programs requiring Digital Rights Management (DRM) will not work under Wine and won't unless and until Linux gets native DRM support. Companies that use DRM, he said, are not willing to help. He gave the latest version of Photoshop as one example of a program that has implemented DRM and will not work in Wine.

There was some interesting virus news last week of a new variant that could infect both Linux and Windows. Newsforge did some testing of it and used Wine in the process. It's not the first time viral code has been run with Wine, though usually results are mixed. One thing that always causes problems is Wine only runs with the permissions granted at the user level. So a normal user can't trash system files owned by root. Microsoft seems to like such holes more than Linus. reviewed CrossOver Office 5.0 as well as Progression Desktop 1.2.3. You might remember that CodeWeavers partnered with Versora a few months ago to support bundling their products together.

Finally, this issue of WWN is horribly late and smaller than it should be. My employer was crazy enough to give me a month off work, so I'm roadtripping across the country. There were a lot of topics on wine-devel over the past few weeks worth covering, I just didn't get to them all here.

Grab a cup of coffee, start reading, and enjoy your Friday.

2. WineConf 2006

27 Apr  (1 post) Archive Link: "Announcing Wineconf 2006, urgent need for head count"

Topics: WineConf 2006

People: Jeremy WhiteRob Shearman

WineConf 2006 is on! This year we're going to England! Jeremy White announced the location and dates this week:

I am pleased to announce that Rob Shearman has arranged for us to have Wineconf in his home town, Reading, in the UK. It will be held at the University of Reading:

It will be on the weekend of September 16 and 17.

We have a wrinkle we need your help on. That is, as we make our deposit (which we need to do quickly), we have to tell them how many rooms we want to reserve.

The have a good deal on rooms (40 pounds/night, which is quite good, afaict).

The trick is that we have to pay for all the rooms we reserve ahead of time; we can't ask for 50 rooms and then only use 43. We have to pay for all 50.

We may be able to ask for 50 rooms, and then get another 3 or 4, although that's not guaranteed.

So, *if you want a room at Wineconf*, please fill in this form ASAP:

If you're not sure you'll make it, but think you might, we have a choice for that too <grin>.

Act now or you'll be sleeping in Swindon...

WineConf is primarily a developer conference. Even if you're just wondering how to get started, feel free to attend. If you've worked on Wine a while and want to meet everyone involved with the project, it's a great event to come to.

3. SambaXP & Wine

25 Apr 2005 (4 posts) Archive Link: "SambaXP update"

Topics: Security

People: Kai BlinRob ShearmanAndrew BartlettGoogle

Kai Blin, who hacked on Wine last year during Google's Summer of Code program, wrote in to inform everyone of happenings at the SambaXP conference. You might recall that last year we had WineConf a few days before that event and met some of the Samba guys. Kai wrote about some issues directly related to Wine:

As SerNet and the Samba team has invited me to SambaXP, I thought I'd give a short update on what happened here so far that is interesting for Wine.

The talks today were only mildly interesting from the Wine point of view, but that chatting with the Samba folks in the breaks was really productive.

I've talked to Steve French about exposing named pipes as file descriptors or fifos and he thinks that should be doable. I have to admit I'm not totally sure what those beasts are needed for, but Juan asked me to bug Steve about. I guess his talk about using CIFS on linux will be interesting, too.

On the SSPI/GENSEC side, I've talked to Andrew Bartlett and Jelmer Vernooij about isolating GENSEC from the Samba code a bit more so it's useable without pulling in too much of the other Samba code (which is also GPL and not useable). They don't seem too happy about releasing GENSEC under the LGPL either, but seem to prefer that to other, less elegant solutions like a wrapper library or a stdio interface.

On the bright side, I managed to get Wine code to compile with GENSEC using some quick hacks. That brings me a bit closer to a proof of concept implementation the Samba people want to see.

The schedule for tomorrow will see more technical talks, and I'll continue to hack on wine-gensec a bit, and of course I'll try to give another report from the conference.

A few days later he wrote in with more info:

Now that SambaXP is officialy over, the samba team a couple of other people have retreated to a smaller room to discuss other things.

Steve French had a talk about using CIFS on linux as a replacement to NFS which seems to be pretty cool. A couple of other talks were given, too, but if you're really interested, have a look at the schedule.

What was more interesting was that after the talks there was a panel discussion where the samba team expressed interest in continuing cooperation with Wine as discussed on last year's wineconf.

Steve asked how exactly we wanted the named pipes exposed and if we could write up some testcases for that stuff. I think if anybody is interested in working on that is to email Steve directly.

I got some more work on GENSEC done, but in order to really link this together, some more work is needed. I still have things blowing up on me when trying to use it for client-side sspi.

Rob Shearman then ran down a list of items he'd like to see:

There are 3 things that Samba could do to help Wine:

  1. Expose SMB operations in a library, including named pipe operations. The library functions exposed would ideally be similar to the Win32 functions, i.e. ConnectNamedPipe, CreateFile, ReadFile, WriteFile, CloseHandle, etc.
  2. Expose an API that would allow Wine (and other applications) to register an endpoint in the Samba endpoint mapper. This API would be along the lines of samba_epm_registerep(UUID *object_uuid, char *protocol, char *endpoint), and a corresponding unregister function.
  3. Create a server that would contain interfaces necessary for DCOM (specified in the draft RFC), plus some other interfaces, like the running object table and ways of registering objects to allow them to be activated. Ideally, these would be compatible with Windows to allow ole32 from NT to be used, but that would require reverse engineering some of the interfaces.

Kai wrote back and said the primary obstacle might end up being licensing and that it would be preferable to find a way to interact without linking to it.

4. Summer of Code Kickoff

14 Apr  (1 post) Archive Link: "Summer of Code 2006 is on!"

Topics: Summer of Code 2006

People: Dan KegelGoogle

Let's just call the rest of this issue of WWN the kickoff to Google's 2006 Summer of Code. For those of you who didn't catch the news, Google is once again sponsoring students to work on open source projects this summer. Wine will once again be one of the participating projects and various Wine developers will serve as mentors for participants. Last year Google funded 400 students and they mentioned this year they'd like to fund even more. Each student will get $4500 paid in three installments; the final portion paid when the project is completed. Applications are due by May 8th, so it's about time to start putting it together. Oh wait.. I remember college.. never mind, you don't need to worry about it until May 7th.

Dan Kegel announced the kickoff of SoC 2006 and described a different strategy for attracting participants:

I've updated, but it's a bit short on project ideas. Somewhat on purpose -- last year, people just copied and pasted our detailed project ideas. This year, lets give fewer details and more ideas... if somebody's really interested, they'll ask for details on wine-devel, and that process will generate fewer boilerplate applications.

There are two weeks before students can submit Summer of Code proposals. How can we use that time to maximize the number of successful projects this year? The students who already have their own good ideas (whoever they are) will probably succeed; we probably need to provide a set of prefab projects of sorts to give guidance to students who are new to Wine and haven't any idea what to work on.

Ideally, each such prefab project would have an active developer (or a close approximation) as project leader and mentor. Are any developers willing and able to come up with a project idea and help mentor/supervise a student to work on it?

As project ideas rolled in, it was difficult to tell if the idea was going to be submitted by the sender of the email or if it was an idea for someone else to work on.

Below you'll find some of the ideas that were presented. The next issue of WWN will contain more, but I'd highly recommend reading wine-devel to see all the project ideas mentioned.

5. SoC: DIB Engine

18 Apr  (6 posts) Archive Link: "SOC: Integrate DIB Engine"

Topics: Summer of Code 2006, Graphics

People: Jesse AllenTroy RolloMike McCormackMichael Stefaniuc

The DIB engine... if you've been a reader of WWN for a while or perused our web pages about various projects that need to be tackled you might have seen references to the mythical DIB engine. It's probably one of the single biggest tasks remaining in Wine and pretty high on a lot of peoples' wish lists. In short, it'd be a 2D rasterizing engine built into Wine that would remove the need for the X server to perform the tasks. It has the potential to drastically speed up 2D rendering and make applications like Photoshop perform much better. Some people have assumed a DIB engine would also make games perform better, but these days most graphics are done with 3D and work on other areas of Wine will improve that performance.

For background on this topic, check out WWN #119 #138 and #159.

So Jesse Allen asked about the DIB engine, " One thing I'd like to try to work on is the DIB engine. Do we need someone to work on it still? This one is also interesting to me because we have some documentation already and that I have worked with bitmaps before too. I'd also like to find out how this stuff might integrate with the current changes going into ddraw. "

Troy Rollo replied first:

Yes. See for more information on this.

This is probably feasible as a SOC project *if* you are familiar with all of the integer-only algorithms for drawing graphics primitives or have a good text book handy that has all the algorithms in it.

Mike McCormack added some words of caution:

Alexandre has very specific ideas about how he wants a DIB Engine done.

Integrating a DIB engine into your own tree may not be too difficult. The hard part is integrating it into the Wine tree in small pieces without breaking everything else and keeping Alexandre happy as you go.

Which led Michael Stefaniuc to remark, " Good! We already have the mentor for this task then ;)"

6. SoC: Early Usage of DLLs

18 Apr  (5 posts) Archive Link: "SOC Idea: Easy usage of native DLLs in Linux programs"

Topics: Summer of Code 2006, Integration

People: Mike Hearn

Mike Hearn's idea might solve a lot of problems other projects have with Wine. We've got some great code but make it pretty difficult to interact with:

Various projects have re-implemented the code necessary to host Win32 DLLs in-process, for instance Xine, MPlayer and GStreamer all have (different) forked, badly hacked copies of the Wine codebase inside themselves to load and use codec DLLs. The GIMP now has the ability to use Photoshop plugins using Wine. And so on.

It'd be nice if there was a simple API programs could use to do this, for instance, wine_dlopen("whatever.dll"), wine_adopt_thread() and so on to make re-use of Win32 components and COM objects easy.

This has been discussed before and Alexandre wasn't sure it was worth it as it'd be a significant extension to the (stable??) Wine APIs, so IMHO this one shouldn't be judged on whether it gets checked in or not but rather whether it works and how easy it is to use.

Thoughts? I know roughly what needs to be done so I could mentor this one, but students be warned - it requires _excellent_ understanding of operating system design and things like threading. There's a reason such a thing doesn't already exist, and it's because it's hard. On the flip side it's not a massive amount of code IMHO so the work would mostly involve learning, debugging, etc rather than simply being a hard typing slog.

Also, a student has all summer and the nice thing is, it's mostly generic computing knowledge that'd be useful for future work (whereas learning a specific api in depth probably isn't ...).

Such a thing has many uses:

I'm sure you can think of some more. Discuss! :)

This stuff probably falls in the realm of hard, but it could be extremely useful.

7. SoC: SafeDisc

23 Apr  (1 post) Archive Link: "SOC Proposal - SafeDisc Support"

Topics: Summer of Code 2006

People: Vijay Kiran Kamuju

Vijay Kiran Kamuju proposed a SafeDisc project:

I would like to propose the SafeDisc Project for wine.

Main Objective: Support for SafeDisc (basically ver 1 Support) Part 1 (Getting the basic IRP support)

Secondary Objective: Have wine specific ntoskrnl.exe that handles this

Requirements: Needs to have in depth knowledge of Win32 Internals as well as wine server internals.

Difficulty: Moderate to High

Mentors: Vitaly Margolen(vitamin) and Alexander Julliard

Details: To implement the SafeDisc Support. The progress and details can be found here

This basically needs the IRP framework for to be implemented for wine (the difficult part).

8. SoC: Java Runtime Environment

22 Apr  (3 posts) Archive Link: "SoC idea: get Sun's JRE working well"

Topics: Summer of Code 2006

People: Dan KegelCodeWeavers

Dan also tossed out the idea of getting a Windows Java JRE working with Wine:

A lot of applications rely on Sun's JRE, some even use it in their installers!

Getting Sun's JRE working properly on Wine would be a great project.

There's been interest in this in the past and some of the CodeWeavers folks have done some work on it. I'm not sure of the exact issues, but I suspect things might be close to working.

9. SoC: finish wcmd

21 Apr  (6 posts) Archive Link: "SoC idea: finish wcmd"

Topics: Summer of Code 2006, Utilities

People: Dan KegelBrandon TurnerSteven EdwardsReactOS

Dan posted another SoC idea: flesh out Wine's cmd.exe replacement, wcmd:

wcmd isn't thought of as sexy, but it's important; for instance, some installers use it under the hood.

Things like

and the /wait commandline flag are not yet implemented. It wouldn't be all that hard to get wcmd far enough along to make those installers happy; I think it'd make a good SoC project.

Brandon Turner from the ReactOS team volunteered to be a mentor and noted, " one of my shorter term goals is to try and sync wcmd" . The ROS implementation is much more complete than Wine's, however it has a legacy that might not make the code portable. Steven Edwards said it was part of the FreeDOS project which is licensed under the GPL (as opposed to Wine's LGPL.) Brandon mentioned that he actually intends to forward port Wine's wcmd to ROS and replace the FreeDOS code, but he hadn't looked into the specifics of it yet.

10. SoC: Better Valgrind Support

19 Apr  (2 posts) Archive Link: "[SOC] proposal -> valgrind"

Topics: Summer of Code 2006, Debugging

People: Eric PouechRob Shearman

Eric Pouech suggested this topic:

Another potential proposal for SOC would be upgrading valgrind to work with Wine.

I've tweaked it a bit (some patches still floating around), but:

I've updated the Wiki page accordingly.

Rob Shearman expanded on the idea:

It would be really good for valgrind know about our heap implementation so that it could report memory leaks. A solution I've done in the past is to change all of the references to HeapAlloc/HeapReAlloc/HeapFree to malloc/realloc/free so that it can report leaks, but that isn't very convenient.

I think that is something that could benefit Wine a lot and wouldn't require very much Wine knowledge at all (although, it could require some knowledge about valgrind).

11. Font and Edit Control Issue

(16 posts) Archive Link: "Wine fonts too big for their input fields."

Topics: Fonts

People: Tony LambregtsDuane ClarkHuw Davies

The devil is in the details.

There's a lot of things Wine does that you probably don't realize how difficult it is to get right. A lot of our dialogs and controls have stabilized over the past few years, and although bugs remain, many of them work well. This week Tony Lambregts brought some attention to some bugs in Bugzilla that are subtle:

We now have at least three bugs[1] where the program will not accept the all the characters that are required if we do not use native fonts. The latest bug report was reported just today and the reporter resolved the bug as FIXED when he used Native fonts.

So I have a couple of questions.

Should we consider using native fonts a "FIX" or is it just a workaround? Or in other words can we fix our built in fonts to fix this.

Should These bugs marked a duplicates? [1]

Duane Clark recognized the problem:

I also have an installer (for Xilinx) that exhibits this problem. I created a small application that creates a single line edit control (which is what the Xilinx installer uses). I notice that on Win2k the EM_GETMARGINS message returns zero for left and right messages, but on Wine it returns 2 for both margins.

From a trace, the margins are getting set to 2 in EDIT_WM_SetFont(), with the call:

Commenting out that single line makes the Xilinx installer work fine. Not that it is the correct fix ;)

Huw Davies thought it might simply be a wrong font substitution in Duane's case but did say there are some difficult issues involved:

I had some fun with this a month or two ago. See the test_margins_font_change test and calc_min_margin_size in the actual code. The deal seems to be that for 'small' edit controls EC_USEFONTINFO results in no margin. 'Small' is currently defined to be smaller than the extents of the (four character) string "'**'", that's close but not quite how Windows does it.

Another interesting thing is that when it does set margins they are often not symmetric left/right (although you tend to have to use larger font sizes to see this) - it's presumably using some pair of font metrics to set these and despite spending quite a while hunting I drew a blank.

Now your problem could simply be that you don't have the font that the app wants to use in this edit control. It'll create the edit control with a size that would work with that font under Windows (and probably also under Wine), however if you don't have that font and Wine picks one which ends up being slightly larger then you've got a problem. It's difficult to know how to fix this. The other possibility is that you have the correct font but the '**' algorithm is slightly wrong (it is) and that you're right on the edge of it kicking in.

There were a lot of back and forth emails. Duane made some screenshots illustrating the issue. The first clearly shows 8's being rendered incorrectly while the second shows 9's correct. A reference on MSDN seemed to at least touch on the issue, but it was confusingly vague on the topic.

Duane then did some more testing and seemed to find a trend, but it still wasn't conclusive as to what was happening.







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.