WWN Issue 233

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

This week, 244 posts consumed 1068 K. There were 65 different contributors. 35 (53%) posted more than once. 32 (49%) posted last week too.

The top 5 posters of the week were:

27 posts in 174K by Shachar Shemesh
26 posts in 75K by Mike Hearn
26 posts in 89K by Dmitry Timoshkov
17 posts in 46K by Alexandre Julliard
13 posts in 38K by Jeroen Janssen

News: Wine Review	07/24/2004	Archive
News So I found this web site this week called Framasoft 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 is pretty harsh, though perhaps not without reason. I think some of the gripes about CodeWeavers are leveled unfairly.

Configuration To-Do List	07/25/2004	Archive
Configuration 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: Windows Look has no associated edit control. Who modifies this setting these days anyway? I vote for killing the label rather than adding the edit. UseTakeFocus (FIXME) - why is this a setting in the UI? I don't even know what the UseTakeFocus protocol does, I've certainly never tweaked it. Does it need to be there? At the very least it needs to be rephrased into terms people can understand and the FIXME needs to be removed. In the Drives tab, the top half is full of widgetry we probably don't want anymore. In particular "Use real windows drive" etc doesn't make much sense, you can just change the c: mapping to get that effect and it's not something we want to encourage anyway. Especially as most people these days seem to use XP rather than Win98 using a real windows drive is fast way to get an inoperable Wine as well as (possibly) a torched Windows install if it's on FAT32 and you can even pick up viruses from them. I kid you not, the other day I ran a program that had been sitting on my Windows XP partition for a few months and my virtual windows drive (I think the term virtual rather than fake sounds better) ended up infected with some W32.Bagle variant. Anyway the top half of this tab doesn't do anything, never did, doesn't make any sense and should just be removed. We should probably merge the X11 Driver and Audio tabs together as they both have lots of empty space, and rename it to "Audio and Video" or something. I think the term "X11 Driver" doesn't make much sense to many people anyway. 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: take audio autodetection out of winecfg and put it in winmm if driver is not found in the registry or the driver fails to load, then autodetect driver 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.

Configuration To-Do List

07/25/2004

Archive

Configuration

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:

Windows Look has no associated edit control. Who modifies this setting these days anyway? I vote for killing the label rather than adding the edit.
UseTakeFocus (FIXME) - why is this a setting in the UI? I don't even know what the UseTakeFocus protocol does, I've certainly never tweaked it. Does it need to be there? At the very least it needs to be rephrased into terms people can understand and the FIXME needs to be removed.
In the Drives tab, the top half is full of widgetry we probably don't want anymore. In particular "Use real windows drive" etc doesn't make much sense, you can just change the c: mapping to get that effect and it's not something we want to encourage anyway. Especially as most people these days seem to use XP rather than Win98 using a real windows drive is fast way to get an inoperable Wine as well as (possibly) a torched Windows install if it's on FAT32 and you can even pick up viruses from them.

I kid you not, the other day I ran a program that had been sitting on my Windows XP partition for a few months and my virtual windows drive (I think the term virtual rather than fake sounds better) ended up infected with some W32.Bagle variant.

Anyway the top half of this tab doesn't do anything, never did, doesn't make any sense and should just be removed.
We should probably merge the X11 Driver and Audio tabs together as they both have lots of empty space, and rename it to "Audio and Video" or something. I think the term "X11 Driver" doesn't make much sense to many people anyway.

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:

take audio autodetection out of winecfg and put it in winmm
if driver is not found in the registry or the driver fails to load, then autodetect driver

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.

rsabase.dll Work	07/25/2004	Archive
Security Michael Jung submitted a patch adding some tests for RSABase.DLL which in turn is responsible for implementing Microsoft's "Cryptographic Service Provider " (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 no 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: Implementation of "real handles", instead of "address-handles". Separating OpenSSL dependent code from CSP code. I consider this beneficial, since there seem to be some license issues with OpenSSL (at least for the ReactOS project - there was a short discussion on this on the wine-devel list). If the OpenSSL code is cleanly separated, it will be easier to support GNUTLS or something later. Basically, my code doesn't do any crypto stuff at all until now (Besides some first lines of code for MD5 hashing). I tried to get the MSDN CryptoAPI examples to compile and run, which only acquire contexts, hash data, derive keys, query CSP params and so on, but which never verify the results. So my code is mainly skin (but elephant skin), no guts. I've attached 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.

rsabase.dll Work

07/25/2004

Archive

Security

Michael Jung submitted a patch adding some tests for RSABase.DLL which in turn is responsible for implementing Microsoft's "Cryptographic Service Provider " (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 no 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:

Implementation of "real handles", instead of "address-handles".
Separating OpenSSL dependent code from CSP code. I consider this beneficial, since there seem to be some license issues with OpenSSL (at least for the ReactOS project - there was a short discussion on this on the wine-devel list). If the OpenSSL code is cleanly separated, it will be easier to support GNUTLS or something later.
Basically, my code doesn't do any crypto stuff at all until now (Besides some first lines of code for MD5 hashing). I tried to get the MSDN CryptoAPI examples to compile and run, which only acquire contexts, hash data, derive keys, query CSP params and so on, but which never verify the results. So my code is mainly skin (but elephant skin), no guts.

I've attached 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.

Wine & Locales	07/28/2004	Archive
Internationalization 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 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 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 exactly what 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, exactly what 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.

Wine & Locales

07/28/2004

Archive

Internationalization

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 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 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 exactly what 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, exactly what 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.

S3 Texture Compression	07/27/2004	Archive
DirectX 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 hasn't been applied, but then again Alexandre has been working remotely all week and there's a good chance he just hasn't caught up.

S3 Texture Compression

07/27/2004

Archive

DirectX

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 hasn't been applied, but then again Alexandre has been working remotely all week and there's a good chance he just hasn't caught up.

To Bugzilla Or Not To Bugzilla	07/24/2004	Archive
Project Management Wine has had a Bugzilla 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 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 devil's advocate :) Always useful to re-examine how we're helping or hindering users, even if the eventual conclusion is that we're doing OK.

To Bugzilla Or Not To Bugzilla

07/24/2004

Archive

Project Management

Wine has had a Bugzilla 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 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 devil's advocate :) Always useful to re-examine how we're helping or hindering users, even if the eventual conclusion is that we're doing OK.

Listing API's in a DLL 07/24/2004 Archive

Listing API's in a DLL	07/24/2004	Archive
Creating Stubs 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)

Creating Stubs

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)

World Wine News