World Wine News

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.

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)

	1250	1251	1252
System	1/1	1/1	1/1
Courier	1/3	1/3	1/3
MS Sans Serif	2/6	2/6	3/6

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.

Hi! My name is Ronald and I was wondering if any of you guys out there can help me get in touch with Mr. Alexandre 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.

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.

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.

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.

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.

Just did not feel like chasing bugs the other day. I decided to have some fun with something that I was wondering about 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

gcc-3.3 -O2 as.c -o as -DASM ; time ./as;time ./as; time ./as

and

gcc-3.3 -O2 as.c -o as ; time ./as;time ./as; time ./as

The resulting times are (all user time):

test#	asm	C
1	15.970	15.899
2	15.966	15.943
3	15.959	15.941
ave	15.964	15.928

Notes:

• tested on a PII 450 MHz;
• I tested with gcc 2.95 and 3.4.2 as well, result are essentially the same.
• size of main() is 0x7a (assembly) vs 0x82 (C-code) bytes;
• I experimented with longer strings to see if there was any mem cache hit/miss effects and found none.

Conclusions:

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.

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!

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 HP-UX, but I don't really have anything to show for it. Before I could get anything working, I had to abandon HP-UX and work on fixing up Linux and Solaris stuff because it was in higher demand. I'll eventually need to get HP-UX 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 HP-UX 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 :-)

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:

http://www.michael-kaufmann.ch/WINE/ControlsRepaintTest.zip

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:

• Redraw immediately: WM_REPLACESEL, EM_SETSEL, WM_CLEAR, WM_PASTE, WM_CUT
• Don't redraw immediately: WM_SETTEXT, EM_UNDO, other messages

Listbox Control:

• Redraw immediately: LB_SETCURSEL, LB_SETTOPINDEX
• Don't redraw immediately: LB_SETSEL, LB_RESETCONTENT, LB_ADDSTRING, other messages