Wine Traffic #233 For 30�Jul�2004

By Brian Vincent

Table Of Contents

Introduction

This is the 233rd issue of the Wine Weekly News publication. Its main goal is to laugh. 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 244 posts in 1068K.

There were 65 different contributors. 35 posted more than once. 32 posted last week too.

The top posters of the week were:

1. News: Wine Review

24�Jul�2004�-�30�Jul�2004 (1 post) Archive Link: "News"

Topics: News

People: CodeWeavers,�,�News

So I found this web site this week called Framasoft (http://www.framasoft.net/article2780.html) that has a pretty detailed list of free software applications. Naturally being curious I had to see what they had to say about Wine. Their critique (http://www.framasoft.net/article2336.html) is pretty harsh, though perhaps not without reason. I think some of the gripes about CodeWeavers are leveled unfairly.

2. Configuration To-Do List

25�Jul�2004 (3 posts) Archive Link: "winecfg todo list"

Topics: Configuration

People: Mike Hearn,�James Hawkins,�Rob Shearman,�Alexandre Julliard,�

Yes.. we continue the ongoing saga of Wine's configuration this week. A lot of folks have been successfully running without the trusty config file, but there's still some work to be done. Mike Hearn summarized the to-do list:

So, I talked with Chris and here are some tasks remaining on winecfg. All of these are *easy* and can be done by anybody who has basic coding ability. For a few of them you don't even really need to know C! So come on lurkers, I know you're out there, step on up.

Things that need to be done before we should switch to winecfg IMHO are:

Minor cosmetic fix: remove the groupbox on the "about" tab, it doesn't provide any information at all. We also may want to stick the authors list in there, as it's a bit more visible than in the shell32 about box which is hardly ever shown. But obviously these things should not block us switching to it.

Once those things are done we can apply the patch to switch Wine to using the registry entirely. Is it worth writing a migration tool?

I'm not really sure, I guess some people would like their settings preserved but most of the settings people tweak are just check boxes in the new UI anyway and would take like 5 seconds to restore. AppDefaults are a bigger issue but do many people have lots of these?

Oh, final thing, we need to double check that removing the config doesn't regress things. I've been running with no config file for a few months now and while there are a few minor things I don't think they are critical. I may well have missed things though.

James Hawkins then began doing a bit of work on those items and more. Among other things he posted a patch changing audio detection:

Changelog:

Rob Shearman was glad to see it, " Thanks for another cool patch. It lessens the burden on the user."

Alexandre didn't like the approach though, " This code does not belong in winmm. Autodetection in winmm should be done by having the drivers themselves fail to load if the corresponding support is missing. "

3. rsabase.dll Work

25�Jul�2004�-�26�Jul�2004 (4 posts) Archive Link: "rsabase.dll"

Topics: Security

People: Rob Shearman,�Michael Jung,�,�Microsoft,�ReactOS

Michael Jung submitted a patch adding some tests for RSABase.DLL which in turn is responsible for implementing Microsoft's "Cryptographic Service Provider (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/csps_and_the_cryptography_process.asp) " (CSP) API's. Rob Shearman warned him, " You seem to be working on Crypto stuff, so I thought I'd better tell you that I've got a patch pending that implements half of the functionality in rsabase."

Michael replied, " Thanks for the information. Indeed I've been working on rsabase.dll. When do you plan to submit your patch? I would like to see if at least some of my code can be incorporated, or if the work was in vain."

Rob must have sent him the patch and fortunately it appears there was a duplication of work:

"

as far as I can tell from looking at your patch, our work is pretty much non overlapping.

I worked on the following aspects:

I've attached (http://www.winehq.com/hypermail/wine-devel/2004/07/att-0425/01-rsabase.diff) the current version of my patch.

Do you have a certain application, which you want to get running? Would it be ok for you if we proceed as follows: I will wait until you submit your patch (It would be nice if you could add some unit-tests that test for behaviour you depend on). After this you give me a week or two to incorporate my work.

Is there any area in rsabase, which you definitely will not implement in the near future and which I could work on until you submit your patch?

"

Rob didn't think he was planning on doing much more work, " Well, pretty much everything that I was going to implement is in the patch I sent you. The only additional functions I was going to implement are RSA_CPSignHash and RSA_CPVerifySignature. However, if you want me to implement some more I would be only too happy to do so having gained a lot of familiarity with both CryptoAPI and the OpenSSL/Crypto library. "

4. Wine & Locales

28�Jul�2004�-�29�Jul�2004 (35 posts) Archive Link: http://www.winehq.com/hypermail/wine-devel/2004/07/0.html

Topics: Internationalization

People: Shachar Shemesh,�Dmitry Timoshkov,�Alexandre Julliard,�

There was a long discussion this week about Wine and setting locales. At times it bordered a flamewar, and it's not clear anything has really been resolved to everyone's satisfaction. Basically the problem revolves around trying to map Unix/Linux's environment settings into Windows and then getting apps to behave appropriately. Needless to say, this is very tricky. In the Unix world there's a set of environment variables (http://publib16.boulder.ibm.com/pseries/en_US/aixprggd/nlsgdrf/locale_env.htm) that control this. In Shachar Shemesh's case he likes to mix and match values of these to get applications to behave in a sane matter. For example, he sets LANG=en_US (US English) and LC_CTYPE=he_IL (Israeli locale for Hebrew) because, " I need to access Hebrew from ANSI applications, but having the user locale (which you call the system locale) set to Hebrew has some undesirable side effects. I therefore have this mixed setting. No problems for me, as I'm not using any characters that belong to the English locale that are outside the ASCII range." So Shachar added support to Wine that took into account LC_CTYPE and then asked that everyone agree on how it should be used:

In an attempt to get away from a possibly confusing subject line, and to converge on an agreed behavior, here is an attempt to clear the desired locale behavior Wine should have. Dmitry (and anyone else), please comment on this table (http://www.winehq.com/hypermail/wine-devel/2004/07/0505.html) where you think there are errors in it, and say what should be there.

In the "Unix setting", I'm always assuming that LC_ALL overrides whatever is written in that column, and that LANG is used if neither LC_ALL nor the column are set.

Dmitry Timoshkov answered:

I said it many times already, and I'll repeat once more: Windows has only one active locale which defines all the things you mentioned in the table except language of the interface which let's set aside to not confuse each other. There is no need to try to find appropriate mappings for LC_TYPE or anything else you find in the output of the 'locale' command. But still (almost) any locale setting you want to modify in the win32 environment on a per user basis can be done either by running Control Panel/Regional Options, or modifying the registry or win.ini directly. By default all locale data are set according to the global system locale.

Any attempt to have more than one active locale simultaneously will lead to confusion and nothing else, be it unix environment or win32.

From there the two went back and forth over exactly what behavior was affected. Shachar was able to point out differences between a systemwide locale setting and one set by a user. Still, Dmitry didn't think it really mattered:

System default locale defines current ANSI code page, while user default locale simply puts the overrides to the registry for numbers, currency, date/time.

I still want your patch to be removed until you at least write test cases showing what exactly APIs are affected by system/user locale. Using LC_CTYPE for the system default locale (current ANSI code page) is very dubious choice as well. The whole purpose and the patch itself are pure hacks aimed to fix unexplaned side effects.

Alexandre, please revert the patch until at least a test case is written and a better explanation provided what exactly wrong with locale controlled by only LC_ALL and LANG.

Shachar felt his interpretation was fine and didn't require any changes. Alexandre agreed, " I'm afraid I still don't see what's wrong with the patch. Obviously there can be different system and user locales on Windows, since there are APIs for that, and LC_CTYPE looks like a pretty good match for what the system locale does; I don't really understand why you are so violently opposed to that patch. Could you please explain exactly what you think this is going to break?"

Dmitry explained what was wrong with it, " It breaks every user's setup where LANG and LC_CTYPE inadvertently point to different locales (like LC_CTYPE=en_US, LANG=ru_RU) and users in that case have completely not working Wine: neither keyboard input, not localized resources and everything else. I, personally, fixed several similar cases for our customers. "

Alexandre didn't exactly understand the problem and asked, " Keyboard input will be affected because we now set the Unix codepage from LC_CTYPE too, is that your main objection?" Dmitry confirmed that was issue. However, Alexandre felt there really was a problem that needed to be solved and asked for some input:

But the fact is that there are two different locales that can be configured independently on Windows, and some users need that ability. So how do you propose to solve the issue?

We could of course make it configurable in the config file instead, but it seems to me that reusing the existing Unix setup is better than requiring users to configure the same thing in two different places.

Dmitry thought that might work, " I like the idea of moving that setting to the config file. We can't use existing unix locale settings except LC_ALL and LANG because every user's system might have (and does have) very different locale settings, we can't assume that everyone out there configures locale in the same way. "

To which Alexandre replied, " I don't see how the settings would be different, surely LC_CTYPE is always going to control the ASCII->Unicode mapping on Unix, so why shouldn't it do that on Wine? If the issue is that users change their setup without understanding the results, then surely adding even more config parameters that they need to get right is not going to improve the situation. "

Dmitry then went back to his original argument that it might just not be needed:

The real question is whether setup with different system and user locale is really used under Windows, and if yes, what exactly purpose is pursued?

In the initial patch Shachar wanted to have English user interface while being able to not break current ANSI codepage support. Instead of implementing MUI for the first part (English user interface) he proposed a simple hack to workaround the problem.

I still ask to show the tests demonstrating what APIs are affected by system and user locale and fix all the places in Wine which behave differently first. Then Shachar might want to write an explanations for the users and add them to documentation how the setup with different system/user locale is supposed to behave. And only after that we can return to discussion what environment variables or config file settings will control such things.

So the way it stands, Shachar's patch has been committed that makes Wine also take into account LC_CTYPE settings.

5. S3 Texture Compression

27�Jul�2004�-�28�Jul�2004 (5 posts) Archive Link: "Re: [D3D] Added native and emulated S3TC support"

Topics: DirectX

People: Mike Hearn,�Lionel Ulmer,�,�Microsoft,�Christian Costa

Microsoft licensed a texture compression scheme from S3 and incorporated it into DirectX a long time ago. In turn, most video card manufacturers licensed the technology. This week Christian Costa posted a patch that added "S3TC" support to Wine's DirectX. It has both native and emulated S3TC support. Mike Hearn asked, " it's my understanding that S3TC is patented, is this also true of the emulation library techniques?"

Lionel Ulmer replied, " Why do you think we took the pain to use an external library to do the decompression instead of having it in the Wine code itself :-) ? " That led Mike to comment, " Great, so this is another codec-style fiasco where you have to violate patents with an extra library if you have the "wrong" video card? What does that mean for distribution? "

Lionel replied:

Anyway, as we use the library that is (or will) be dynamically loaded by the DRI code, the packaging issue will be already solved for us for the DRI.

Basically, only people like me with pre-GeForce NVIDIA cards will need to do the extra steps of actually installing the library, all others will either have hardware support or have it installed via the DRI package.

The patch still hasnt been applied, but then again Alexandre has been working remotely all week and there's a good chance he just hasn't caught up.

6. To Bugzilla Or Not To Bugzilla

24�Jul�2004�-�29�Jul�2004 (19 posts) Archive Link: "Is bugzilla worth keeping?"

Topics: Project Management

People: Mike Hearn,�Ivan Leo Puoti,�Steven Edwards,�Shachar Shemesh,�Dan Kegel,�

Wine has had a Bugzilla (http://bugs.winehq.org) bug tracking system for a while now (well, we lost the database once, but some kind folks fixed it up.) Like any project, including paid commercial development, it's hard to maintain that bug list. Mike Hearn wondered if we should just get rid of it:

One thing I notice about most other open source projects is that they have many more flamewars than we do. So, I thought I'd start one:

It strikes me, looking at the wine-bugs list, that there is a huge disparity between the number of people maintaining it and the number of people filing bugs in it. It seems to be quite rare for communication on bugfixes to take place there, wine-devel is the more usual forum.

So are we misleading users by having a bugzilla into thinking that if they file a bug there, it'll be fixed when it probably won't?

If so, does it matter?

If we were to simply drop bugzilla, how would it impact the project?

The answer seemed to be a resounding no. Ivan Leo Puoti summed up a bunch of the reasons people liked it, " Of course we should keep it. It's a place to track bugs, and keep everything related to a non working application in the same place. And if we didn't have it, people would just flood the devel list with bug reports, or not report at all, and non of them seem a great idea. I've got a couple bugs fixed with bugzilla, and if wine will ever be finished then eventually all the bugs will be fixed. And not really we get messages on the patches list with patches that fix something in bugzilla. And it's a good place to send developers that aren't sure what to do next. "

There were even more reasons, such as Steven Edwards':

Yes sometimes if I am bored and looking for something to do I will search bugzilla and pick a random bug that can either be fixed or needs to be closed because it is fixed in a more recent CVS.

Shachar Shemesh:

I use bugzilla as a tool to keep track of my "todo" list. If there is a place where I suspect a certain behaviour is broken, I open a bug report (knowing it will only be me who will have to "confirm" it... :-), and leave it "unconfirmed".

Dan Kegel:

It would deprive us of long-term memory. For instance, I filed the bug report #1404 (http://bugs.winehq.org/show_bug.cgi?id=1404) in January 2003 with a nice test case (but one that's hard to translate into a unit test). Without Bugzilla, we'd have a harder time remembering problems like that.

There was a lot of sentiment expressed that it's too bad there aren't resources (read: people) available to help maintain the current bugs. For example, some things might be fixed in there and haven't been cleaned out. Someone who could write test apps could also greatly help out by identifying the source of a problem (even if they can't fix it.) Mike concluded it indeed was worth keeping, " I don't have any strong opinion on the matter, I was just playing devils advocate :) Always useful to re-examine how we're helping or hindering users, even if the eventual conclusion is that we're doing OK."

7. Listing API's in a DLL

24�Jul�2004�-�25�Jul�2004 (4 posts) Archive Link: "how can I find what functions a dll file provides?"

Topics: Creating Stubs

People: James Hawkins,�Diefo Petteno,�Andreas Mohr,�,�Microsoft

James Hawkins asked a question that comes up from time to time, " In what way can I list the API functions provided from a certain dll file? I seem to remember seeing somewhere that you could use a debugger, but I'm not sure. "

Diego Petteno suggested, " I usually use Dependency Walker ( http://www.dependencywalker.com/) which works fine under wine (seems strange because it's a Microsoft product, but that's it ;) It's also useful to track down which dlls uses an executable and then try to load the native ones. "

Andi Mohr also suggested using one of Wine's tools, " wine/tools/winedump/ (now even with 16bit NE file support) "

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.