various config files for various applications
hello everybody! i know it was already at least mentioned here - how to provide config file that works without change for more than one application. what do you think about this concept? the changes to config file are relevant to some sections only. i think these are important: * [DllDefaults], [DllOverrides] * [wine] - because of path variable, some programs want to have something specific there * [x11drv] - for example something runs better in managed mode, something not * i'm not quite sure about [fonts], [spooler] so probably we need to make these sections application dependent. when we parse the config file we don't have a lot information about the application we're going to run - in fact the file name only. anyway that's probably enough. so maybe we could add the new optional sections like [x11drv-homesite*.exe]. the string after "-" sign could be an case insensitive regular expression. when some of this x11drv optional sections match the condition about its filename, it's taken and no more x11drv sections are considered. if not, the default non-optional x11drv section is taken. i think we shouldn't follow some "inherit" concept because it could dim things a lot. simple "this and only this section is valid" should be enough. and of course there have to be some trace message which section was really used. i believe this could significantly increase the number of applications which run fine with the default config file we provide. of course the ideas how to improve/wholly change this concept are welcomed. martin
i know it was already at least mentioned here - how to provide config file that works without change for more than one application. what do you think about this concept?
The problem here is the server. I notice that if you start one application with --managed, all applications started afterwards also get this set, if the server is still active when they start. I think the server should store its preferences in a process specific area that can be set per-process (but by default would use the .wine/config setup). Everything else should be overridale on the command line, perhaps? One nice thing about this would be the ability for a (gui?) wine utility to read and change those defaults for a process using server calls. Debug messages could be turned on/off, for example, while the server is still running. Being able to browse the servers process/thread tree, attach a debugger externally etc could also useful. This would require a small set of 'server broswer' calls to be made available, and the current global preferences such as tweak_winelook to be held by the server. However, its a fair bit of work, and unlikely to happen in the immediate future AFAICS. Cheers, Jon -- "Don't wait for the seas to part, or messiahs to come, Dont you sit around and waste this chance ..." -Live tntjpgriff(a)tsnxt.co.uk , jon_p_griffiths(a)yahoo.com
i know it was already at least mentioned here - how to provide config file that works without change for more than one application. what do you think about this concept?
The problem here is the server. I notice that if you start one application with --managed, all applications started afterwards also get this set, if the server is still active when they start.
I think the server should store its preferences in a process specific area that can be set per-process (but by default would use the .wine/config setup). Everything else should be overridale on the command line, perhaps?
One nice thing about this would be the ability for a (gui?) wine utility to read and change those defaults for a process using server calls. Debug messages could be turned on/off, for example, while the server is still running. Being able to browse the servers process/thread tree, attach a debugger externally etc could also useful.
This would require a small set of 'server broswer' calls to be made available, and the current global preferences such as tweak_winelook to be held by the server. However, its a fair bit of work, and unlikely to happen in the immediate future AFAICS.
i see the point. however, let's say the wineserver isn't running, so we're able to do things we want to do. i know it's not perfect, but it's a good first step, i think. then we can continue. martin
hello again! after discussion we discovered quite big lack of this model: maintenance. the config file could easily exceed any reasonable size, and that is something we probably don't want (wine-users: send your config file...). so here is the revision: application specific config information could be stored in separate directory (let's say ~/.wine/app-config), one configuration per file. each file will contain an entry which determines its validity, e.g. "Filename" = "homesite*.exe". then there will be the [DllOverrides] section and maybe some others. this breaks wine configuration into two pieces: application independent part (stored in ~/.wine/config, contains drives, paths and all other independent stuff) and application dependent part (stored in ~/.wine/app-config, contains things like [DllOverrides]). on startup wine will load ~/.wine/config and pass through files stored in ~/.wine/app-config directory. the first match against regular expression defined in these files (Filename=...) causes to overwrite some sections from ~/.wine/config. the advantage is much easier maintenance. the disadvantage could be that you can't see the whole configuration in ~/.wine/config file anymore - some settings could be overwritten by optional file in ~/.wine/app-config. what do you think? martin
the advantage is much easier maintenance. the disadvantage could be that you can't see the whole configuration in ~/.wine/config file anymore - some settings could be overwritten by optional file in ~/.wine/app-config. well, what I don't like too much is the time at process startup to look up for the correct file (if it exists). Especially if people start writing app specific files like rabbits. Couldn't we put a speed up in the file look up ? Something easy like naming the config file after the first letter of the application... (I know it'll break *foo.exe, but it shouldn't be too much of an issue). Future work may also include version information if available (think of winword.exe for example ; all of those are rather different apps)
regarding configuration, another point which really bugs me is also the content of the registry. I fear this is going to cause us lots of trouble in the future... and may be we'll need application specific keys in the registry... A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle
well, what I don't like too much is the time at process startup to look up for the correct file (if it exists). Especially if people start writing app specific files like rabbits. Couldn't we put a speed up in the file look up ? Something easy like naming the config file after the first letter of the application... (I know it'll break *foo.exe, but it shouldn't be too much of an issue).
another way could be have some additional (let's say ~/.wine/app-config/1database.txt) file which will contain <regular expression> --> <filename> mappings. that way wine have to open (and read) only that file, and we're able to do that pretty fast (as i found out when worked on registry patch). however, it has to evaluate all the reg. expressions at runtime, but that is linear dependency. hmm, i don't know now. first letter or an additional file?
Future work may also include version information if available (think of winword.exe for example ; all of those are rather different apps)
well, this doesn't look easy, but we will have to handle it somehow. probably by the set of conditions (as the part of application database file) which allows you to do simple checks for files and maybe their content also in order to determine if it's the right version (so the file settings can be applied). however, as you said, it's something for future work.
regarding configuration, another point which really bugs me is also the content of the registry. I fear this is going to cause us lots of trouble in the future... and may be we'll need application specific keys in the registry...
for "wine with windows" it should work - registry will be there from windows partition. for "wine without windows" the install program should add them. and if it relies on some keys which aren't installed by installer, then those keys should be part of winedefault.reg file. martin
well, what I don't like too much is the time at process startup to look up for the correct file (if it exists). Especially if people start writing app specific files like rabbits. Couldn't we put a speed up in the file look up ? Something easy like naming the config file after the first letter of the application... (I know it'll break *foo.exe, but it shouldn't be too much of an issue).
another way could be have some additional (let's say ~/.wine/app-config/1database.txt) file which will contain <regular expression> --> <filename> mappings. that way wine have to open (and read) only that file, and we're able to do that pretty fast (as i found out when worked on registry patch). however, it has to evaluate all the reg. expressions at runtime, but that is linear dependency. hmm, i don't know now. first letter or an additional file?
Future work may also include version information if available (think of winword.exe for example ; all of those are rather different apps)
well, this doesn't look easy, but we will have to handle it somehow. probably by the set of conditions (as the part of application database file) which allows you to do simple checks for files and maybe their content also in order to determine if it's the right version (so the file settings can be applied). however, as you said, it's something for future work.
regarding configuration, another point which really bugs me is also the content of the registry. I fear this is going to cause us lots of trouble in the future... and may be we'll need application specific keys in the registry...
for "wine with windows" it should work - registry will be there from windows partition. for "wine without windows" the install program should add them. and if it relies on some keys which aren't installed by installer, then those keys should be part of winedefault.reg file. martin
participants (4)
-
Eric Pouech -
Jon Griffiths -
Martin Pilka -
Martin Pilka