Re: mshtml #2: Added warning if a wrong Wine Gecko package version was found.
Jacek Caban <jacek(a)codeweavers.com> writes:
@@ -212,8 +213,10 @@ static BOOL load_wine_gecko(PRUnichar *gre_path) if(res != ERROR_SUCCESS || type != REG_SZ) return FALSE;
- if(TRACE_ON(mshtml)) - check_version(gre_path); + /* We may consider message box here */ + if(ERR_ON(mshtml) && !check_version(gre_path)) + MESSAGE("Found a version of Wine Gecko package that is not dedicated " + "to your Wine version. Reinstalation is recommended.\n");
If you want to check versions, there needs to be a way to specify in the URL which version you want to download, and old versions need to be kept available. The target CPU should also be part of the URL so we can support multiple platforms. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
Jacek Caban <jacek(a)codeweavers.com> writes:
@@ -212,8 +213,10 @@ static BOOL load_wine_gecko(PRUnichar *gre_path) if(res != ERROR_SUCCESS || type != REG_SZ) return FALSE;
- if(TRACE_ON(mshtml)) - check_version(gre_path); + /* We may consider message box here */ + if(ERR_ON(mshtml) && !check_version(gre_path)) + MESSAGE("Found a version of Wine Gecko package that is not dedicated " + "to your Wine version. Reinstalation is recommended.\n");
If you want to check versions, there needs to be a way to specify in the URL which version you want to download, and old versions need to be kept available.
Yes, that's my plan, but I'm not sure why it's important for this patch. Currently Wine downloads always the same Gecko version that was never updated, so this check should work with current Wine. It will change once we will switch to the new version. I have patches that will use query encoded in URL to specify the package version and it will use the same defined version string as version check in this patch, so switching to the new Gecko won't be much more than one line patch.. It requires changes both in Wine and redirecting php script. I have patches for both and this was the first patch in this direction. I only have to test the rest of patches and send them (hopefully I will find the time to do it tonight).
The target CPU should also be part of the URL so we can support multiple platforms.
We are very far from being able to support other archs, so I thought it's not worth to care about it ATM. Thanks, Jacek
Jacek Caban <jacek(a)codeweavers.com> writes:
Yes, that's my plan, but I'm not sure why it's important for this patch. Currently Wine downloads always the same Gecko version that was never updated, so this check should work with current Wine. It will change once we will switch to the new version. I have patches that will use query encoded in URL to specify the package version and it will use the same defined version string as version check in this patch, so switching to the new Gecko won't be much more than one line patch.. It requires changes both in Wine and redirecting php script. I have patches for both and this was the first patch in this direction. I only have to test the rest of patches and send them (hopefully I will find the time to do it tonight).
My concern is that this sort of thing needs to be planned correctly to work in the long run, and it's not clear what the purpose of that version check is. Is there a dependency that would make Wine require a specific version? What happens if you use a new Gecko with an old Wine? Can you make different versions coexist?
We are very far from being able to support other archs, so I thought it's not worth to care about it ATM.
But then there's no sense in adding #ifdefs for it. Putting the architecture in the request wouldn't be much harder, and would avoid hardcoding in the client knowledge about what files are available on the server. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
Jacek Caban <jacek(a)codeweavers.com> writes:
Yes, that's my plan, but I'm not sure why it's important for this patch. Currently Wine downloads always the same Gecko version that was never updated, so this check should work with current Wine. It will change once we will switch to the new version. I have patches that will use query encoded in URL to specify the package version and it will use the same defined version string as version check in this patch, so switching to the new Gecko won't be much more than one line patch.. It requires changes both in Wine and redirecting php script. I have patches for both and this was the first patch in this direction. I only have to test the rest of patches and send them (hopefully I will find the time to do it tonight).
My concern is that this sort of thing needs to be planned correctly to work in the long run, and it's not clear what the purpose of that version check is. Is there a dependency that would make Wine require a specific version? What happens if you use a new Gecko with an old Wine? Can you make different versions coexist?
The plan is to pass the version in URL query. Then the redirecting script will take care on choosing the correct file from SourceForge. It's backward compatible as older Wine won't pass the version so script will assume that an old Gecko is requested. The new Gecko doesn't work with old Wine (that's why we have to guaranty that it will download an old Gecko). It's because we depend on some Gecko behaviors that have changed. It's both due to Wine (we have to do some not nice tricks, to not say ugly hacks, to make loading document work correctly) and not perfect backward compatibility of Gecko. Also it's not guarantied that newer Wine will work with older Gecko. Currently it will work, that's why I think simple message is enough for now to not force people to download over 5MB if their apps work without it. But we have to use some unfrozen interfaces and they may change in the future preventing backward compatibility. Although we probably could add some workarounds when it will happen, I would be painful to support few Gecko version. So if it will happen in the future, then we can change this check to never use older Gecko (and perhaps add a nice updater). By coexisting different versions you mean in one Wine prefix? Yes, it would be possible, but I don't see much point of it. If you think it should be done this way, I may implement so (it prevents current patches, these changes would be in another peace of code).
We are very far from being able to support other archs, so I thought it's not worth to care about it ATM.
But then there's no sense in adding #ifdefs for it. Putting the architecture in the request wouldn't be much harder, and would avoid hardcoding in the client knowledge about what files are available on the server.
I've sent patches that replace previous ones. There are removed #ifdefs. We may back to arch problem later, just like we do now with different versions. Thanks, Jacek
Jacek Caban <jacek(a)codeweavers.com> writes:
The plan is to pass the version in URL query. Then the redirecting script will take care on choosing the correct file from SourceForge. It's backward compatible as older Wine won't pass the version so script will assume that an old Gecko is requested. The new Gecko doesn't work with old Wine (that's why we have to guaranty that it will download an old Gecko). It's because we depend on some Gecko behaviors that have changed. It's both due to Wine (we have to do some not nice tricks, to not say ugly hacks, to make loading document work correctly) and not perfect backward compatibility of Gecko. Also it's not guarantied that newer Wine will work with older Gecko. Currently it will work, that's why I think simple message is enough for now to not force people to download over 5MB if their apps work without it. But we have to use some unfrozen interfaces and they may change in the future preventing backward compatibility. Although we probably could add some workarounds when it will happen, I would be painful to support few Gecko version. So if it will happen in the future, then we can change this check to never use older Gecko (and perhaps add a nice updater).
One problem with your version scheme is that there's no obvious way of determining which version is newer, or compatible. A simple string comparison won't work for that purpose.
By coexisting different versions you mean in one Wine prefix? Yes, it would be possible, but I don't see much point of it. If you think it should be done this way, I may implement so (it prevents current patches, these changes would be in another peace of code).
A wine prefix dir needs to be portable across Wine versions, you should be able to upgrade/downgrade Wine while keeping the prefix dir. So if compatibility across Gecko versions is not guaranteed we have to support installing multiple versions in parallel. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
One problem with your version scheme is that there's no obvious way of determining which version is newer, or compatible. A simple string comparison won't work for that purpose.
By coexisting different versions you mean in one Wine prefix? Yes, it would be possible, but I don't see much point of it. If you think it should be done this way, I may implement so (it prevents current patches, these changes would be in another peace of code).
A wine prefix dir needs to be portable across Wine versions, you should be able to upgrade/downgrade Wine while keeping the prefix dir. So if compatibility across Gecko versions is not guaranteed we have to support installing multiple versions in parallel.
I've sent a patch that fixes these issues. Now we have the supported version, that is installed by installer, and 'known to work' versions, that are checked while searching the installation. Strings are enough to identify the version. We have only a short list (currently one, two will be soon) of versions to check. The compatibility with older version will get worse in the future and someday we may decide to remove older version from the list (by then most users will probably have newer Gecko installed). As each Gecko version is installed in a different location and in target location we expect specific version, I've changed the version check in the loading code to fail if it finds an unexpected version. It will probably be a good idea to add an option to identify a Gecko installation that is not checked against versions to make testing different Geckos easier. I hope it is an acceptable solution. Thanks, Jacek
participants (2)
-
Alexandre Julliard -
Jacek Caban