Hello!
I read on another thread that the config file is going to disappear in future wine versions. While I think that the dosdevices-principle is a good idea (it's very intuitive), there are several disadvantages in moving the content of the config file to the registry:
1. Even if the registry keys and values of wine's configuration should be well documented, it's easier to set some values using a text editor than to use regedit and look for the keys.
2. Although it might be convenient to access both, wine's and the Windows programs' data, using the same functions, this should not be done as there should be a clear distinction between wine and the programs it runs.
3. If a program misbehaves and messes up your registry and/or if you decide to start again with a clean installation, you just delete some registry files and directories and have a new system (I think of the case you don't work in a native Windows installation) without to setup wine's configuration again.
4. To put wine's configuration into the registry is a step towards a "Wine-is-Windows", i.e. not just providing Windows' functionality but also behaving like Windows (and this should be avoided under all circumstances ;-) ). Wine is "just" an emulator for Windows, it is not supposed to be a new "Open Source Windows". The Windows' handling of configuration data (every application puts its data into the same two files: the registry) is inferior compared to the Unix' one's (every application has its own configuration file/directory in a common place). This makes it difficult e.g. to manually deinstall a program/software package.
Well, my opinion. What do you think about it?
Adrian Willenbücher wrote:
- Even if the registry keys and values of wine's configuration should be
well documented, it's easier to set some values using a text editor than to use regedit and look for the keys.
We know that, this is why we're:
a) Eliminating as many config options as possible b) Writing winecfg to configure the rest graphically
- Although it might be convenient to access both, wine's and the Windows
programs' data, using the same functions, this should not be done as there should be a clear distinction between wine and the programs it runs.
You realise that the config file was already mounted into the registry on startup right? This is just about moving files around really. It has one BIG advantage also, namely that we can write a graphical editor for it! It's really hard to do that with the current config file even though they have the same syntax.
- If a program misbehaves and messes up your registry and/or if you decide
to start again with a clean installation, you just delete some registry files and directories and have a new system (I think of the case you don't work in a native Windows installation) without to setup wine's configuration again.
- To put wine's configuration into the registry is a step towards a
"Wine-is-Windows", i.e. not just providing Windows' functionality but also behaving like Windows (and this should be avoided under all circumstances ;-) ). Wine is "just" an emulator for Windows, it is not supposed to be a new "Open Source Windows". The Windows' handling of configuration data (every application puts its data into the same two files: the registry) is inferior compared to the Unix' one's (every application has its own configuration file/directory in a common place). This makes it difficult e.g. to manually deinstall a program/software package.
Well, my opinion. What do you think about it?
I think you need to open up ~/.wine/system.reg in a text editor and observe that it has a nearly identical syntax to the config file ;) Exporting a configuration is just a matter of copy/paste. Importing becomes "regedit myconfig.reg". There are currently no plans to move to a binary registry format.
thanks -mike
We know that, this is why we're:
a) Eliminating as many config options as possible
Although this increases simplicity, it also narrows the user in his possiblities to adjust wine to his needs. To take away configuration options from the user seems to be a trend within the wine developers' community ;-) Why do you do this? Wine users are Linux users (although they run Windows applications). They _want_ to be able to configure their software to the limit (while at the same time being able to install a package and start working - but this is no contradiction!).
b) Writing winecfg to configure the rest graphically
In fact I try to do as much work as I can within a terminal. If I have the (reasonable) choice between GUI and TUI, I choose TUI (and I'm not an old Linux guru). Why? Well, at first it's cool :-D , but I also hate pushing the mouse and moving the right hand from keyboard to mouse and back. I don't know how many other Linux users think similar about this. What's so bad about having a text file with all options? In other words: What advantages would a graphical, specialized tool have? Of course, it simplifies wine's configuration for first-time users, but think about the disadvantages: 1. It has to be written. While a developer writes winecfg, he could also hack wine and improve it. 2. It has to maintained. Whenever there is a new option, winecfg has to be updated. 3. It has to be documented as well as config file has to be documented. So this is no pro for winecfg. 4. It narrows choices. If the user wants some unusual config, he will have to edit the registry files manually. This problem already appears at the very beginning with wineinstall: If I don't want to install wine in /usr/local but in /home/addy/wine (because wine changes so often that it's easier and more secure not to have to be root every time I update it), I have to edit wineinstall. (wineinstall is just an example of the overall trend)
There's no problem (from user's point of view) about a config file coexisting with a graphical tool editing this file.
- Although it might be convenient to access both, wine's and the
Windows
programs' data, using the same functions, this should not be done as
there
should be a clear distinction between wine and the programs it runs.
You realise that the config file was already mounted into the registry on startup right? This is just about moving files around really.
That's not the point. Wine's configuration should not be mixed with Windows programs' configuration, because the one is wine and the other ones are the programs which are run by wine. Wine is _not_ another Windows application so its data has nothing to do in the registry. The only reason why wine implements the principle of the registry should be that Windows applications use it, but not wine. Reason:
- To put wine's configuration into the registry is a step towards a
"Wine-is-Windows", i.e. not just providing Windows' functionality but
also
behaving like Windows (and this should be avoided under all
circumstances
;-) ). Wine is "just" an emulator for Windows, it is not supposed to be
a
new "Open Source Windows". The Windows' handling of configuration data (every application puts its
data
into the same two files: the registry) is inferior compared to the Unix' one's (every application has its own configuration file/directory in a common place). This makes it difficult e.g. to manually deinstall a program/software package.
It has one BIG advantage also, namely that we can write a graphical editor for it! It's really hard to do that with the current config file even though they have the same syntax.
Why (just curious)?
- If a program misbehaves and messes up your registry and/or if you
decide
to start again with a clean installation, you just delete some registry files and directories and have a new system (I think of the case you
don't
work in a native Windows installation) without to setup wine's
configuration
again.
- To put wine's configuration into the registry is a step towards a
"Wine-is-Windows", i.e. not just providing Windows' functionality but
also
behaving like Windows (and this should be avoided under all
circumstances
;-) ). Wine is "just" an emulator for Windows, it is not supposed to be
a
new "Open Source Windows". The Windows' handling of configuration data (every application puts its
data
into the same two files: the registry) is inferior compared to the Unix' one's (every application has its own configuration file/directory in a common place). This makes it difficult e.g. to manually deinstall a program/software package.
Well, my opinion. What do you think about it?
I think you need to open up ~/.wine/system.reg in a text editor and observe that it has a nearly identical syntax to the config file ;) Exporting a configuration is just a matter of copy/paste.
First you have to find all places containing wine's configuration. Then you have to copy/paste all those pieces and hope you didn't forget one ;-).
Importing becomes "regedit myconfig.reg".
So you have to start wine in order to setup the configuration in order to start wine. Do you think this is a good way?
Adrian
Although this increases simplicity, it also narrows the user in his possiblities to adjust wine to his needs.
How many options in the config file do you adjust? I mean, really, options like:
* PerfectGraphics: what does this do? Hands up anybody who can tell me without grepping the source. How many people set it?
* DesktopDoubleBuffer: This is "necessary" only until the WM rewrite is complete, at that point we can make the right choice on the fly depending on the applications requests instead of requiring the user to somehow know what it is and how to set it.
* UseTakeFocus: I never did find out what this is :)
etc etc. There are a lot of options in there that are "bogus" options, the user cannot know how to set them correctly without a god-like understanding of the Wine/Windows/X11 internals. These are what I am referring to when I say we are removing them.
Options like your drive mappings, what Windows version to emulate (as our heuristics often get this wrong) and whether to use desktop mode are being left in. Though actually the plan for desktop mode is to (eventually, I hope) integrate AJ Pasydns patch to make it a separate app so you can run "winedesktop foobar.exe" if you want to swallow it in a desktop.
To take away configuration options from the user seems to be a trend within the wine developers' community ;-) Why do you do this? Wine users are Linux users (although they run Windows applications). They _want_ to be able to configure their software to the limit (while at the same time being able to install a package and start working - but this is no contradiction!).
It's a trend within the whole open source community really, because people woke up and realised that our software was full of stupid options where the cost outweighed the gain (or as is the case with Wine, where even the developers no longer knew what they did!).
In fact I try to do as much work as I can within a terminal. If I have the (reasonable) choice between GUI and TUI, I choose TUI (and I'm not an old Linux guru).
That's fine, so edit the reg files with emacs or whatever.
- It has to be written. While a developer writes winecfg, he could also
hack wine and improve it.
Yes, but ease of use does take time ....
- It has to maintained. Whenever there is a new option, winecfg has to be
updated.
No. Whenever there is a new option it should have a smart default and really Wine is not something users should interact with directly. It should Just Work and be invisible in the background.
They interact with their applications. Very, very few options should be exposed to the user - most of our current options are covering up for the fact that Wine sometimes doesn't have enough information to make the right decision on a per-app basis (or that we can't know at runtime). With smart coding most of these bugs can be fixed so Wine makes the decision for the user (and is always right).
- It has to be documented as well as config file has to be documented. So
this is no pro for winecfg.
Most config file options are currently undocumented anyway, and many are very tricky to explain even if they were documented.
- It narrows choices. If the user wants some unusual config, he will have
to edit the registry files manually. This problem already appears at the very beginning with wineinstall: If I don't want to install wine in /usr/local but in /home/addy/wine (because wine changes so often that it's easier and more secure not to have to be root every time I update it), I have to edit wineinstall. (wineinstall is just an example of the overall trend)
Well you can always use the graphical regedit tool. This was a requirement for 0.9 for exactly this reason.
Wineinstall is not meant for users like you, it's meant to be a single "install me" command. If you want to control the defaults just do what you'd normally do:
./configure --prefix=/whatever && make depend && make install
That's all there is to it these days.
It has one BIG advantage also, namely that we can write a graphical editor for it! It's really hard to do that with the current config file even though they have the same syntax.
Why (just curious)?
The code to load/save/lock/read registry files is already written and is well tested. That's why the config file is internally accessed via the registry APIs in Wine (though I sometimes wish it wasn't, the win32 registry API is very awkward).
To do that for the config file whilst preserving comments, whitespace etc would be very difficult and require separate code.
First you have to find all places containing wine's configuration. Then you have to copy/paste all those pieces and hope you didn't forget one ;-).
Not really, it's all under one branch. And you can use the graphical regedit tool (shipped as part of Wine) to do the export if you really want.
Importing becomes "regedit myconfig.reg".
So you have to start wine in order to setup the configuration in order to start wine. Do you think this is a good way?
Sure. Like I said, I have been running with no config file for some months now -> no problem :)
Wine should not require configuration. Therefore if it needs a config file, we're doing something wrong!
-
"Adrian Willenbücher" -
Mike Hearn