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

Wine Traffic #241 For 24 Sep 2004

By Brian Vincent

Table Of Contents


This is the 241st issue of the Wine Weekly News publication. Its main goal is to glow in the dark. 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 85 posts in 375K.

There were 40 different contributors. 15 posted more than once. 26 posted last week too.

The top posters of the week were:

1. News: SourceXtreme

18 Sep 2004 - 24 Sep 2004 (1 post) Archive Link: "News"

Topics: News

People: NewsforgeIan GeiserNewsForgeMicrosoftNews

NewsForge announced a product by SourceXtreme to move Windows application development to Linux using Wine, Qt, and some other open source programs. The details provided by NewsForge are a bit scarce, they state:

Working with Qt, Trolltech's cross-platform toolkit, MinGW, a minimalist set of GNU utilities for Windows, and Wine, a free implementation of the Windows API, SourceXtreme, Inc. has developed the ability to write Windows programs without ever using Windows. Its goal is to make porting applications to Qt trivial, and to move Windows developers onto a free software platform.

It does beg the question though, what exactly is Wine used for? Obviously apps running on Windows don't require Wine. I asked Ian Geiser of SourceXtreme about it and he outlined three different ways Wine comes into play:

This last point is interesting because the toolkit used to develop apps is Qt. The applications developed rely on the Win32 version of Qt, not the Linux one, which is in turn completely supported by Wine's implementation of the Win32 API. Ian also added, " Wine with the binfmt kernel support has been indispensable in our ability to remove Microsoft from our Windows development work."

2. Fonts Status

20 Sep 2004 - 21 Sep 2004 (5 posts) Archive Link: "Re: fonts: 20 ppem Wine Sans Serif"

Topics: Fonts

People: Huw DaviesMike HearnSteven EdwardsMicrosoftReactOSTransGaming

Last week (WWN issue #240) we discussed a bit of the new fonts being added. Dimi asked this week what the current status is and what remains to be done. Huw Davies outlined the work and where everything is at:

We have replacements for MS Sans Serif, Courier, System and Marlett. Marlett is a TrueType font and that's essentially complete thanks to TransGaming.

The others are bitmap fonts and under Windows these come in localized versions and also in two resolutions (96 and 120 dpi). I've only been working on the 96 dpi strikes so far and the table summarizes the number of strikes compeleted/no in Windows for each font in a given codepage. (1250 - east europe, 1251 - cyrillic, 1252 - latin 1)

Actually the cp1251 sets aren't quite 100% complete as there are a few non-Russian characters that Dmitry hasn't done.

There is nothing so far for Greek, Turkish, Hebrew or Arabic codepages. and we're entirely missing MS Serif, Terminal and Small fonts.

We're also missing replacement TrueType fonts for Tahoma and Microsoft Sans Serif (which is different from MS Sans Serif!) - these are considerably more effort than the bitmap ones.

On the coding side of things, we'll need a way to select which set of bitmap fonts are used based on the current locale.

Font development isn't something to be taken lightly and it led Mike Hearn to ask about TrueType fonts, " Are these the ones where they need to be correctly hinted which costs bazillions of dollars? Or, is it actually feasable to do them just with volunteer effort? "

It seems that, while time consuming, it's certainly possible for someone to tackle font creation. Steven Edwards mentioned that the ReactOS project is working on this as well, " We have a Tahoma replacement (Greenville) coming from ReactOS which is almost done the only problem is the developer is not using fontforge to create it. I dont remeber the name of the tool but it is a very expensive font creation program. "

He provided a link to a screenshot of the new Greenville font.

3. SpecOps Labs Steps Up

22 Sep 2004 (3 posts) Archive Link: "Contributing to WINE"

People: RonaldAlexandre JulliardShachar ShemeshMike McCormackSpecOpsLabsCodeWeaverscodeweaversJeremy WhiteNewsTransGamingCodeweavers

Remember Project David that got some attention a few months ago? (See WWN issues #220, #222, #225, and #234 for more details.) We've been a bit critical of them in the past because it's not exactly clear they have a product, what role Wine might play in it, or if they intend to keep their work behind closed doors. Well, this week someone stepped forward and finally came forward to the community:

Hi! My name is Ronald and I was wondering if any of you guys out there can help me get in touch with Mr. Alexander Julliard or any of the leaders here in the WINE community. We've been trying to get in touch with him for months now and we have consistently failed to receive a response.

My company, SpecOps Labs, would like to discuss how we can contribute and work together with the WINE community. We believe we have a lot to contribute to the WINE community. However, without contact with any of the executives at WINEHQ, we are unable to do so.

We want to engage in an initial dialog with Mr. Julliard. Our CTO has already tried emailing him twice. It's possible we don't have the right contact information. We'd greatly appreciate it if someone here could help us out.

Alexandre said he did reply and reiterated his response:

I got his mails and replied (even though they were sent as Word documents which was a big pain to read). I imagine he never got the replies, it seems your mail setup needs some work.

As I said in my replies, the best way to talk with the community is to post here on wine-devel; if you have patches you want to contribute to Wine send them to wine-patches. And please try to send your mails in plain text.

Shachar Shemesh described a bit about how the Wine community is organized and other useful tips:

First, allow me to say that it is a pleasure to finally hear from SpecOps directly. So far, all the communication between your company and this project have been through press releases on your part, and public responses on ours. I am hoping we will all find that direct communication is a better way to conduct both business and development.

I cannot answer for Alexandre regarding your inquiries with him. I am not even sure what "leaders in the WINE community" mean. As a free software project, wine has no executives, as it is not a body with a legally standing existence.

If the cooperation discussion you wish to conduct is of a technical nature, the best way to conduct them is here, on this list. If it is of a legal nature, I'm not really sure what your legal standing would be. Legally, Wine belongs to its copyright holders, many of them can be reached through this list, but not all of them. Neither Alexandre, nor any other single person or entity, can approve activities that require all copyright holder's consent. This includes, among other things I'm probably forgetting, selling the code and changing the code's license to something not LGPL compatible.

If what you are after is hired work to help you in development, you have several options. First of all, to the best of my knowledge, there are three companies that today have the know how to provide such services. These are CodeWeavers, TransGaming who mostly work on their own proprietary variant of Wine, and my company, Lingnu. There may also be other companies I am not aware of. Your best bet with any of those is to go through the "contact information" on their web site.

In addition to that, some of the wine hackers on this list also work as free lancers. I am sure that directing a request to this list asking for hired help will provide you with people willing to sell you their time and knowledge.

Mike McCormack described how to go about submitting patches:

You submit patches against Wine, Alexandre commits them or perhaps tells you how the patches can be improved. Open source means everybody gets to see the code, and Wine is an LGPL project. We welcome new contributors!

If you're looking for cooperation on a product, you'll better contact Jeremy White of Codeweavers.

Taking a look at the SpecOps Labs website you can find a quite a few changes from what appeared earlier in the summer. It does appear they're trying different approach than Wine, though Wine is being utilized in some manner. Interestingly, there is now a little footnote on the one page that reads:

The WINE Project was one of the pioneers of Linux-Windows compatibility and we are appreciative of WINE's 10+ years of service to the Linux community. As stated above: "our DAVID Technology is utilizing certain components of the WINE Project" any modifications that we make to these components will be made available to the open source community.

4. Removing 'Optimized' Assembly

21 Sep 2004 - 22 Sep 2004 (5 posts) Archive Link: "optimized assembly functions in wine"

Topics: Fixes

People: Rein KlazesAlexandre JulliardRein Klaze

Wine has had some hand-coded assembly for a couple of multibyte capable string functions, strcpyW and strlenW. Rein Klazes took a look at exactly why we bother and put together an interesting test:

Just did not feel like chasing bugs the other day. I decided to have some fun with something that I wondering for a long time: the usefulness of inline i86 assembly in string functions.

This is the test program as.c

The function strcpyW is a copy from Wine with the #ifdef modified.

I used the following commands


The resulting times are (all user time):



  1. these routines are so fast that it is hard to imagine that these functions will be a bottleneck, justifying such optimization;
  2. nothing shows here that inline assembly brings any advantage.

It was pointed out that the assembly could be even further optimized. Still, it seemed pretty hard to justify having assembly when the compiler seemed to do a pretty good job. Alexandre agreed, " You are right, that assembly code is more confusing than helpful. I've removed it."

5. HP-UX Port

22 Sep 2004 - 23 Sep 2004 (3 posts) Archive Link: "Getting winebuild to work on HP-UX"

Topics: Ports

People: Warren BairdAlexandre JulliardEric Frias

Speaking of assembly language.. Warren Baird wanted to know if so much of it was necessary since it was causing a problem porting Winelib to other architectures:

As I mentioned in a previous post, I'm working on getting winelib to run on an HP-UX / PA-RISC system. The biggest problem I'm facing right now is dealing with all of the assembly code that is put into the .spec file by winebuild. I'm not an expert at assembly of any form, and I know absolutely nothing about PA-RISC assembly.

I guess my main question is: why is so much assembly needed there - can some or all of it be replaced by C code (at least on platforms where you never need to interact with real windows libs - like sparc/solaris and pa-risc/hpux)?

Any suggestions on how to get this code working on hpux would be really helpful!

Alexandre broke the bad news, " No, pretty much everything that can be done in C already is, the rest really needs to be in assembly. It's a perfect opportunity to learn PA-RISC assembly <g>"

Eric Frias mentioned he had done some work on it, but was never able to finish it:

I'm afraid I won't be a lot of help right now, but I might be able to offer some moral support. I've spent several weeks last year trying to get winelib working on HPUX, but I don't really have anything to show for it. Before I could get anything working, I had to abandon HPUX and work on fixing up Linux and Solaris stuff because it was in higher demand. I'll eventually need to get HPUX working also, but I won't be able to devote too much time to it for at least a month.

I was in the same situation as you are... very rusty at x86 assembly, able to comprehend a little sparc assembly, but I didn't know a thing about pa-risc. I was simply typing make, letting it run until it had some error because HPUX wasn't supported, coming up with some fix for it, and repeating. Some days I felt like I almost grasped what was going on and how to fix it, and some days it felt like it was miles away. I never got all of wine compiling, so I have no idea if any of the fixes I made were correct or not. I'd be happy to share them with you, but seeing them might do you more harm than good.

Anyway, good luck, and if you weren't looking for an excuse to learn pa-risc assembly, well, you have my sympathies. I'm told it builds character :-)

6. UpdateWindow vs. WM_PAINT

20 Sep 2004 - 21 Sep 2004 (2 posts) Archive Link: "UpdateWindow vs. WM_PAINT"

Topics: Controls

People: Michael KaufmannMichael Kaufman

Michael Kaufmann came up with a patch that fixed the way controls repaint themselves:

I've noticed that many Windows controls don't wait for a WM_PAINT message. They redraw themselves immediately (with GetDC/ReleaseDC, UpdateWindow or RedrawWindow). This is necessary if a program is carrying out a lengthy operation without fetching messages. TextPad is such a program: Its progress control doesn't get updated in WINE while loading a file.

To see the redraw differences between Windows and WINE, I've created this test program:

It changes properties of different controls and then calls Sleep() to simulate a lengthy operation.

The big problem is that it's undocumented in which cases a control should wait for a WM_PAINT message and in which cases it should redraw itself immediately. I've observed that many controls redraw themselves immediately if an important property of the control gets changed (e.g. the position of a progress control, the text of a status bar) or if the user selects an item (ListBox, ListView, TreeView) or if he presses a key (Edit box). Most controls wait for WM_PAINT if the data that they display was modified. But sometimes it's just arbitrary.

Examples (tested on Windows 2000):

Edit Control:

Listbox Control:

Alexandre hasn't committed the patch yet, so if you have an app suffering from buggy drawing in controls you may want to try out Michael's patch.







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.