Mike Hearn wrote:
There are a bunch of different ways we may want to upgrade the users configuration:You did address most of the situations right. I have some scenarios that should be taken into account.
- Changes to $WINEPREFIX (~/.wine), for example:
- Introducing faked DLL headers - Improved drive detection - Changing the way the registry is stored - Adding stuff to the virtual Windows drive
- Modifying the registry
- Adding new keys - Adding new appdefaults (default config options should be in the code itself). While we have a policy of not having app-specific hacks in Wine, some situations are very hard to resolve without custom overrides. The Internet Explorer installer does a bunch of things we really don't want it to do. The DCOM installer needs custom overrides to convince it to install. And so on. - Registering new COM DLLs
(these all boil down to rerunning wine.inf)
- Adding new binaries such as fonts, PE DLLs (think Moz AX control), and so on. These may be placed somewhere in the Wine install directory and then symlinked or copied (presumably linked) into drive C.
This leads to the following questions:
- How do we know when to upgrade the users wineprefix? - How do we avoid disturbing the users configuration? - What implementation do we use to upgrade it?
One potential implementation for knowing when to upgrade the wineprefix is to version it in a similar manner to how we version the wineserver protocol: with a simple incrementing integer. This could be stored in the registry, and Wines initialization sequence changed to be:
...
Does $WINEPREFIX exist? No, call wineprefixcreate - Continue with startup + Yes? Check the wineprefix version key, if it is < the + version compiled into the source run + "wineprefixcreate --upgrade $oldversion $newversion", which then + performs the upgrade. If it exits with a zero exit code, the + version key is set to the number compiled into the source. + Then continue with startup
If registry access is too difficult here, a simpler implementation could be used: just store the number in a .version file.
How do we avoid disturbing the users configuration? Alexandre already laid out the plan for this, which is to have HKLM (HKEY_LOCAL_MACHINE) devoted to the defaults we cunningly choose for maximum kewlness, and HKCU (HKEY_CURRENT_USER) is where the users settings are stored. These override the defaults, meaning we can change the default settings by altering wine.inf, then bumping the wineprefix version so triggering a remerge of the default registry contents.
This means modifying each piece of code where we read the registry to figure out a user-configurable option. The algorithm becomes:
* Check the relevant key in HKCU, if it exists use it * Otherwise, if it's an appdefault, check the same key in HKLM * Otherwise, use the hardcoded default
In most cases, there's no point in duplicating the points at which we can control the defaults, doing it in the code is fine. So, it basically means grepping the source to find out where we read settings from, and changing them to use HKCU instead of HKLM, perhaps also reading HKLM depending on the context of the setting (settings that can be used in appdefaults should check both).
I don't know how common these settings are but it might be worth having a utility function either in a DLL or inline in a header to do this. Registry code isn't complicated but it is tedious and easy to mess up, so we might as well reduce code duplication at the same time.
I think the best implementation is to keep the code responsible for managing WINEPREFIX in wineprefixcreate, and simply extend this program to handle upgrades as well. OK, so the name will be a bit inaccurate but let's not change it - users are already discovering the new program and getting used to it, no need to modify it now especially as it's mostly an internal program.
In the above example the old version and new version numbers were passed to wineprefixcreate but most of the time that information wouldn't be needed, for instance if we were to introduce fake DLL headers we could simply check if they already existed and skip that part if so. I think there's no harm in running wine.inf multiple times, so we could just do that every time for both creation and upgrade.
I *think* this addresses most of the issues with upgrades, though I'm sure Alexandre can think of more :) Potential unresolved problems:
- [How] do we lock wineprefix during upgrade so other processes that are run hang about until it's done?
- Currently moving registry keys about is done actually in the code itself: we copy it across then print a message telling the user to delete the old setting manually. There's a fair bit of evidence that some users simply don't spot/understand these warnings. Also, we want to allow people to upgrade Wine with quite long intervals in between yet eventually this code gets deleted.
Maybe a better solution is just to have wineprefixcreate understand how to move registry keys around in response to bumping the version. If the script gets too unwieldy, we could split particular upgrades into separate scripts in $prefix/share/wine.
- Are there any wierd setups where parts of wineprefix are shared between different users/systems that we need to take into account?
Thoughts? Comments?
thanks -mike
1. It is more than common to use more than one wine version on the same prefix. So what will the older version do. is it always future compatible?
2. Please do not silently touch a user's wineprefix. Users are used to have their wineprefix untouched. It is common practice to have a good solid production environment. And than try a new wine to see if a particular issue was fixed. The last thing they need is to later see that something was broken. Just have the check in place. and do a big FIXME. Than if the user uses a --upgrade command line switch. The actual upgrade is made. Or Just have the FIXME instruct the user to directly use wineprefixcreate for the upgrade. This way the user knows he/she needs to backup before running the new wine.
Free Life Boaz
