Re: [PATCH 16/16] tools/wine.inf: Quote the winebrowser executable in the shell open command.
"James Hawkins" jhawkins@codeweavers.com writes:
diff --git a/tools/wine.inf.in b/tools/wine.inf.in index 4756d7d..bc1b1d6 100644 --- a/tools/wine.inf.in +++ b/tools/wine.inf.in @@ -128,7 +128,7 @@ HKCR,folder\shell\open\ddeexec,,2,"[ViewFolder("%l", %I, %S)]" HKCR,folder\shell\open\ddeexec,"NoActivateHandler",2,"" HKCR,folder\shell\open\ddeexec\application,,2,"Folders" HKCR,hlpfile\shell\open\command,,2,"%11%\winhlp32.exe %1" -HKCR,htmlfile\shell\open\command,,2,"%11%\winebrowser.exe -nohome" +HKCR,htmlfile\shell\open\command,,2,"""%11%\winebrowser.exe"" -nohome" HKCR,htmlfile\shell\open\ddeexec,,2,"""%1"",,-1,0,,,," HKCR,htmlfile\shell\open\ddeexec,"NoActivateHandler",2,"" HKCR,htmlfile\shell\open\ddeexec\Application,,2,"IExplore"
This isn't look right, the entry works just fine without quotes, we shouldn't have to add them just to satisfy a test.
On Mon, Oct 20, 2008 at 6:25 AM, Alexandre Julliard julliard@winehq.org wrote:
"James Hawkins" jhawkins@codeweavers.com writes:
diff --git a/tools/wine.inf.in b/tools/wine.inf.in index 4756d7d..bc1b1d6 100644 --- a/tools/wine.inf.in +++ b/tools/wine.inf.in @@ -128,7 +128,7 @@ HKCR,folder\shell\open\ddeexec,,2,"[ViewFolder("%l", %I, %S)]" HKCR,folder\shell\open\ddeexec,"NoActivateHandler",2,"" HKCR,folder\shell\open\ddeexec\application,,2,"Folders" HKCR,hlpfile\shell\open\command,,2,"%11%\winhlp32.exe %1" -HKCR,htmlfile\shell\open\command,,2,"%11%\winebrowser.exe -nohome" +HKCR,htmlfile\shell\open\command,,2,"""%11%\winebrowser.exe"" -nohome" HKCR,htmlfile\shell\open\ddeexec,,2,"""%1"",,-1,0,,,," HKCR,htmlfile\shell\open\ddeexec,"NoActivateHandler",2,"" HKCR,htmlfile\shell\open\ddeexec\Application,,2,"IExplore"
This isn't look right, the entry works just fine without quotes, we shouldn't have to add them just to satisfy a test.
The value is quoted in Windows; what's the harm in matching that? The test in question was added to fix an installer (can't remember which one now), and the recently added tests now show that msi is correct, while the current value of the command is incorrect.
"James Hawkins" jhawkins@codeweavers.com writes:
The value is quoted in Windows; what's the harm in matching that? The test in question was added to fix an installer (can't remember which one now), and the recently added tests now show that msi is correct, while the current value of the command is incorrect.
The command is supposed to be editable by the user, so we can't depend on a specific format. Also since it's editable it won't be automatically upgraded, so for backwards compatibility we have to handle the current format anyway.
On Mon, Oct 20, 2008 at 12:19 PM, Alexandre Julliard julliard@winehq.org wrote:
"James Hawkins" jhawkins@codeweavers.com writes:
The value is quoted in Windows; what's the harm in matching that? The test in question was added to fix an installer (can't remember which one now), and the recently added tests now show that msi is correct, while the current value of the command is incorrect.
The command is supposed to be editable by the user, so we can't depend on a specific format. Also since it's editable it won't be automatically upgraded, so for backwards compatibility we have to handle the current format anyway.
Even if it is editable, I don't see what the problem is with making this the default value. Susan Craig has already run into this problem with the DNS 10 installer, which uses the AppSearch action to search for IE using this value. I don't know the policy of the shell command values, but maybe the executable has to be quoted if options are given.
"James Hawkins" jhawkins@codeweavers.com writes:
Even if it is editable, I don't see what the problem is with making this the default value. Susan Craig has already run into this problem with the DNS 10 installer, which uses the AppSearch action to search for IE using this value. I don't know the policy of the shell command values, but maybe the executable has to be quoted if options are given.
Making it the default value can be done, but that doesn't solve the problem. You can't require that people blow away their ~/.wine for the installers to work again, we are supposed to be backwards compatible with the Wine 1.0 registry.
-
Alexandre Julliard -
James Hawkins