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 #251 For 3 Dec 2004

By Brian Vincent

Table Of Contents


This is the 251st issue of the Wine Weekly News publication. Its main goal is to configure a new laptop. 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 207 posts in 931K.

There were 64 different contributors. 37 posted more than once. 29 posted last week too.

The top posters of the week were:

1. News: Wine-20041201

27 Nov 2004 - 3 Dec 2004 (1 post) Archive Link: "News"

Topics: News

People: Alexandre JulliardMike HearnJason EdmeadesRob ShearmanNewscvs

It's been a few weeks since we've seen Alexandre tag a new version of Wine in CVS, so it wasn't too surprising to see one this week:

WHAT'S NEW with Wine-20041201: (see ChangeLog for details)

Alexandre noted the Direct3D changes, but we're also seeing the beginning of some major work on other areas of Wine. The next release or two of Wine will likely see massive changes to Direct3D, windowing, and OLE/COM. If you're interested in that stuff, look for patches from Jason Edmeades, Alexandre, Mike Hearn, and Rob Shearman, respectively.

2. Desktop Integration Tasks

27 Nov 2004 - 28 Nov 2004 (10 posts) Archive Link: "Fun desktop integration tasks"

Topics: Integration

People: Mike HearnDiego PettenoAlban BrowaeysSteven EdwardsStefan DosingerIvan Leo PuotiReactOS

Mike Hearn took a few minutes to come up with some tasks that could really help users:

I'm sitting waiting for a couple of compiles to finish, so I thought I'd put together a list of fun/interesting tasks people might like to have a go at related to better integrating Wine with the native desktop.

None of these should be especially hard, and so would provide a good intro to Wine development for anybody who has been lurking on the sidelines and wants to get involved.

As usual no guarantees these patches would be accepted, that's Alexandre's call. But they probably would be, and you'll learn something while doing them! :)

Task 1:

Task 2:

Task 3:

Task 4:

Task 5:

Task 6:

Diego Pettenò commented on task #5, " In kde the command is 'kfmclient openUrl <url>'. "

Alban Browaeys had a suggestion for task #4:

wineshelllink supports update-menu which itself builds xdg compliant menus (via /etc/menu-methods/menu-xdg).

I know mandrake and debian distro use "menu", need confirmation for RH/Novell newest releases.

It would be more elegant to let menu manage gnome/kde/xgd/wmaker ... than reimplementing them in wineshelllink . The strongest point is that menu build menu via methods which are tweakable by distro builder. Thus it will avoid to upgrade wineshelllink whenever we want to support gnustep xdg version 12 and the like.

Steven Edwards added another idea:

I would like to add support to use the draft FreeDesktop trashcan spec. I am working on this a little with one of the ReactOS guys but it will be a while before we have a patch ready.

Stefan Dösinger suggested another:

Another suggestion, probably a bigger task: Look for common native applications and write entries for them into the registry. For example, I manually added an entry for KMail in \\Machine\\software\\clients and now I can select Kmail as the default Mail application in the internet options control panel(Which is created when Internet Explorer is installed). My registry entries look like this:

I selected KMail as the default Mail application, and when I open an Mail Address in MSIE kmail pops up. The same happens when I enter a mailto: address in Task Manager->New task.

Then Mike came up:

Implement a bridge between the Windows registry and the GNOME/KDE configuration systems. If you set the wallpaper in a Windows app it should reflect on your real desktop. This is useful for programs like the WebShots desktop.

Actually I already have the code for such a "wineshell" program in a local tree, for the system tray integration. I'll see if I can get it submitted soon. We could put all this integration stuff there once it's integrated into Wine.

Ivan Leo Puoti added one more, " Get xscreensaver to respect the registry LowPowerActive setting. "

3. Wine Bug Busters

30 Nov 2004 - 1 Dec 2004 (20 posts) Archive Link: "Bug Busters"

Topics: Debugging

People: James HawkinsTony LambregtsWineHQ

James Hawkins wanted to get everyone's thoughts about getting developers together to smash bugs in Wine:

I have a totally non-original idea for sessions called Bug Busters where, at a designated time, a group of wine developers would get together on #winehackers (or some other channel). We would pick a bug (or maybe more) from wine's bug tracker and work together to fix the bug(s). This would serve several good purposes. First, we would be giving more attention to wine's bugzilla and getting rid of a lot of those bugs. Second, many newcomers can witness and take part in the wine development process. I'm sure everyone can remember how daunting it is to jump into wine development. Anyway, if anyone has any ideas or would like to take part in this, let me know and we'll get this started.

There were more suggestions and James summarized them, " I agree that programs should be freely available to anyone if the bug requires a program. Some of the bugs don't need them. I also agree that the older bugs should be fixed first. We might even find that a bunch of bugs we try to fix have already been fixed (it's good to clean up bugzilla too). My thought is that we would pick the bugs before the sessions so that anyone interested can research the problems beforehand and we know what we're going to work on for the session. Another option is that we pick the bugs to work on during the session. I think both options are convenient and worth considering. It's ultimately up to the community though. "

Tony Lambregts expanded on some of those ideas:

There is nothing wrong with fixing a bug for its own sake and any bug we fix will ultimately improve wine and provide some insights into debugging wine.

That being said, I would agree that at least to some degree this should be a training exercise and that whatever bug(s) we go after, some (budding?) developer would like to have fixed. However there should be a bug report in bugzilla so that developers can research the bug in the first place and we can keep track of what was done for these sessions. I have created a key word "BugBuster" in Bugzilla to keep track of candidates. Hopefully after several sessions we will have a list of fixed bugs that new developers can use as a reference.

More details were discussed, such as what time it should be held to attract developers in both the US and Europe. During the course of discussion, James confirmed that #winehackers on IRC would be used to get everyone together (see WineHQ for details on Wine's IRC channels.) Finally, after more discussion, it was decided that the first Bug Buster session would be held on Sunday, Dec 5th, at 7pm GMT (2pm EST).

4. RichEdit (con't)

27 Nov 2004 (4 posts) Archive Link: "No RichEdit20A window class"

Topics: Controls

People: Krzysztof FoltmanMike McCormack

Last week (WWN #250) some discussion about the RichEdit control outlined the amount of work that needed to be done to support the latest incarnation of it. Mike McCormack said there was just a lot to do and work hadn't even started. This week Krzysztof Foltman wrote in to say he had done some work on it:

Just for the record, I'm still trying to develop a "proper" RichEdit control. I've written from scratch with RichEdit compatibility in mind, so I don't expect any copyright or suitability problems. At least, unless I screw something up or I'm less smart than I think.

If someone isn't afraid of running closed-source .exe from barely known developer (or can run it in a controlled environment), you can find the latest binary at:

I'm not releasing the source yet, because I don't think it's hackable, until at least its architecture is complete. What's more, I'm planning to license a heavily modified derived product comercially to some company (a rich text viewer/editor tailored for a specific application), so any copyright-related problems are undesirable.

What IS done:

What isn't done:

Mike encouraged Krzysztof to just make it available:

I have been working on richedit a little also, and am quite keen to get the ball rolling by having some richedit 2.0 code in winehq so that others can help work on it. I'm quite interested to see the source for this.

Whether you show us or not, the copyright for the source still belongs to you. If you choose to license it under LGPL, then you can still release it under a different license later, so long as you are the sole author.

I think you'll find that the development proceeds much quicker if you release your source, and get it integrated into the Wine tree sooner rather than later. People will submit patches fixing your code, and new features.

When you do release your "completed" riched20 code, LGPL patches will still be submitted against it, and you'll experience the same licensing problems if you wish to incorporate other people's code.

Frankly speaking, people promising to release their source code "at a later date" are an impedement to development, because nobody is motivated to work on the promised feature in the meantime.

Please consider "release early, release often", so we can work together on this :)

5. IE Installer Script (con't)

27 Nov 2004 - 29 Nov 2004 (7 posts) Archive Link: "Changed IE6 install script to run IE6 completely out-of-box"

Topics: Fixes

People: Hajime SegawaMike Hearn

Last week (WWN #250) I mentioned Hajime Segawa came up with a new installer script for Internet Explorer. I also mentioned that he "cheated" by making it depend on native DCOM. This week Segawa changed the script and announced:

I changed the install script a bit and it does not depend on DCOM98, MFC4.0, etc... anymore. So, you can run IE6 completely out-of-the-box.

New script is here :

Mike Hearn had some suggestions for improving it further:

Quick tip: if you grab the IEBATCH file from my IE installer script:

and put it in your script then the IE installer won't prompt the user for any information when installing. This is good as not all the things it would otherwise install work yet. Also it makes it a fully automatic hands-free install which I quite like.

Segawa rewrote his script to include it and announced some more changes, " Internet Explorer setup can be downloaded during install. Multi language support started."

Mike Hearn, who wrote another IE installer script last year, asked if he could redirect users to Segawa's page since his script was unmaintained. Segawa thought that was fine. Christian Britz then offered to translate it into German. The current version of the script is 1.6.2 and can be found at:

6. Darwine SDK

2 Dec 2004 (1 post) Archive Link: "Preliminary Darwine SDK Released"

Topics: Winelib, Ports

People: Sanjay ConnareMicrosoft

Wine and Winelib, although intricately bound together, really serve two different audiences. Whereas Wine is normally used to just run existing Windows binaries, Winelib holds the promise of being able to take the source code of a Windows application and recompile it as a native application. In theory, Microsoft could use it to make Word run on Solaris.

However, Winelib apps still require Wine in order to have little details, like windowing, function. In another thread recently, someone was disappointed to learn this. However, since there's no performance penalty incurred it's not a huge deal and more of a cosmetic issue. In fact, Dimi pointed out the Winelib toolchain addresses it by creating a wrapper script.

Anyway, Sanjay Connare announced a Darwine SDK this week for MacOS X:

I have released a preliminary version of the Darwine SDK version 0.1. Many people are interested in getting Darwine up and running so they can compile programs on OS X and this release should satisfy their curiosity. The SDK features the following:

The Xcode integration allows for a user to compile windows source code from within the Xcode IDE using the wine tools. Users may want to note that there are some changes to the way Darwine is installed and functions. Due to limitations in Xcode, the wine source tools such as winegcc, winemaker, winebuild are installed in the /usr/bin directory and not the /Library/Darwine/bin directory. This may be changed in a future release but was necessary so Xcode integration would work correctly. As a result there is an updated uninstaller as well. The uninstaller will remove everything except for the Xcode project template folder, which is moved to the trash and needs to be removed manually.

To start a new Darwine project, simply launch Xcode, select new project, and select Darwine (Windows) Application. Currently in Xcode the "Build and Run" does not work, it will build the program but not launch. However, the Build button works as expected. When compiling a Darwine application for the first time Xcode may give the error:

Open a terminal and type the following command:

<name> being replaced by the name of the library whose table of contents is out of date.

The source code should then compile fine. There are many examples of source in the wine source code "programs" folder which is located in the root of the source directory. Simple programs should compile fine. However, bigger programs that depend on more of the windows headers will probably not compile due to header incompatabitlies between the wine and OS X headers.

You can download the preliminary release here or through the Darwine web site

Post any comments, questions or concerns to the Darwine Mailing List "" .

Remember this is a preliminary release and there are many bugs and issues that need to be worked out and features that need to be implemented. More information will be posted on the Darwine website in the near feature.

Last but not least enjoy.







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.