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.

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

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?

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.

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.

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.

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.

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.

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.

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?

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".

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.