On Fri, Oct 1, 2010 at 4:29 AM, Alexandre Goujon ale.goujon@gmail.com wrote:
diff --git a/dlls/mshtml/mshtml.inf b/dlls/mshtml/mshtml.inf index d7d2428..dea1712 100644 --- a/dlls/mshtml/mshtml.inf +++ b/dlls/mshtml/mshtml.inf @@ -273,6 +273,7 @@ HKLM,"Software\Microsoft\Internet Explorer\Default Behaviors","TIME",, "CLSID:47
[WineGecko.Reg] HKCU,Software\Wine\MSHTML,"GeckoUrl",,"http://source.winehq.org/winegecko.php" +HKCU,Software\Wine\MSHTML,"GeckoCabDir",,"/usr/share/wine/gecko/"
The directory isn't always /usr/share, it's relative to where wine is installed
On 10/01/2010 12:17 PM, Austin English wrote:
On Fri, Oct 1, 2010 at 4:29 AM, Alexandre Goujonale.goujon@gmail.com wrote:
diff --git a/dlls/mshtml/mshtml.inf b/dlls/mshtml/mshtml.inf index d7d2428..dea1712 100644 --- a/dlls/mshtml/mshtml.inf +++ b/dlls/mshtml/mshtml.inf @@ -273,6 +273,7 @@ HKLM,"Software\Microsoft\Internet Explorer\Default Behaviors","TIME",, "CLSID:47
[WineGecko.Reg] HKCU,Software\Wine\MSHTML,"GeckoUrl",,"http://source.winehq.org/winegecko.php" +HKCU,Software\Wine\MSHTML,"GeckoCabDir",,"/usr/share/wine/gecko/"
The directory isn't always /usr/share, it's relative to where wine is installed
dll/mshtml/install.c: 541 * Try to find Gecko .cab file in following order: 542 * - directory stored in GeckoCabDir value of HKCU/Software/MSHTML key -> install_from_registered_dir() 543 * - $datadir/gecko -> install_from_default_dir() 544 * - download from URL stored in GeckoUrl value of HKCU/Software/MSHTML key -> DialogBoxW(hInst, MAKEINTRESOURCEW(ID_DWL_DIALOG), 0, installer_proc); 545 */
The above comment says : (1) the default way to find gecko is to look at the registry value (2) if not found, try to find gecko relatively (3) fallback : ask the user to fetch it from the Internet
(1) can't work as GeckoCabDir is not defined in the registry So currently, wine can only find gecko with (2)
My git-wine directory is at /home/alex/Projects/wine/ So when I run `/home/alex/Projects/wine/wine winecfg` with an empty ~/.wine, it looks for gecko in /home/alex/Projects/wine/../gecko/ Or gecko is present in /usr/share/wine/gecko as I installed the wine1.3-gecko package
This patch does not break the current behavior and let people who are running wine in some weird prefix to use the packaged gecko
I read again http://wiki.winehq.org/Gecko and /usr/share/wine/gecko/ seems to be the default path
Anyway, thanks for your comment but I think it's Jacek Caban who have to answer and say if I'm right or wrong.
On 10/1/10 1:06 PM, GOUJON Alexandre wrote:
On 10/01/2010 12:17 PM, Austin English wrote:
On Fri, Oct 1, 2010 at 4:29 AM, Alexandre Goujonale.goujon@gmail.com wrote:
diff --git a/dlls/mshtml/mshtml.inf b/dlls/mshtml/mshtml.inf index d7d2428..dea1712 100644 --- a/dlls/mshtml/mshtml.inf +++ b/dlls/mshtml/mshtml.inf @@ -273,6 +273,7 @@ HKLM,"Software\Microsoft\Internet Explorer\Default Behaviors","TIME",, "CLSID:47
[WineGecko.Reg]
HKCU,Software\Wine\MSHTML,"GeckoUrl",,"http://source.winehq.org/winegecko.php" +HKCU,Software\Wine\MSHTML,"GeckoCabDir",,"/usr/share/wine/gecko/"
The directory isn't always /usr/share, it's relative to where wine is installed
dll/mshtml/install.c: 541 * Try to find Gecko .cab file in following order: 542 * - directory stored in GeckoCabDir value of HKCU/Software/MSHTML key -> install_from_registered_dir() 543 * - $datadir/gecko -> install_from_default_dir() 544 * - download from URL stored in GeckoUrl value of HKCU/Software/MSHTML key -> DialogBoxW(hInst, MAKEINTRESOURCEW(ID_DWL_DIALOG), 0, installer_proc); 545 */
The above comment says : (1) the default way to find gecko is to look at the registry value (2) if not found, try to find gecko relatively (3) fallback : ask the user to fetch it from the Internet
(1) can't work as GeckoCabDir is not defined in the registry So currently, wine can only find gecko with (2)
That's intended. It's for overwriting defaults (although now that we install Gecko during wineprefix creation is doesn't make much sense anyways).
My git-wine directory is at /home/alex/Projects/wine/ So when I run `/home/alex/Projects/wine/wine winecfg` with an empty ~/.wine, it looks for gecko in /home/alex/Projects/wine/../gecko/ Or gecko is present in /usr/share/wine/gecko as I installed the wine1.3-gecko package
This patch does not break the current behavior and let people who are running wine in some weird prefix to use the packaged gecko
I read again http://wiki.winehq.org/Gecko and /usr/share/wine/gecko/ seems to be the default path
Anyway, thanks for your comment but I think it's Jacek Caban who have to answer and say if I'm right or wrong.
You can't do that. The default is what's found by 'step (2)' from your description, not any hardcoded path. The version from Gecko package is meant for packaged Wine. You should copy the .cab file to appropriate directory for your own build.
Jacek
That's intended. It's for overwriting defaults (although now that we install Gecko during wineprefix creation is doesn't make much sense anyways). You can't do that. The default is what's found by 'step (2)' from your description, not any hardcoded path. The version from Gecko package is meant for packaged Wine. You should copy the .cab file to appropriate directory for your own build.
Ok, so I'm wrong. Sorry for the noise in this case.
Jacek Caban jacek@codeweavers.com writes:
You can't do that. The default is what's found by 'step (2)' from your description, not any hardcoded path. The version from Gecko package is meant for packaged Wine. You should copy the .cab file to appropriate directory for your own build.
I don't think there would be any harm in trying some global paths even when running from the build tree, so that people can install their distro's wine-gecko package and have private builds take advantage of it. But of course this should be done directly in the code, not by changing the default registry entry.
On 10/1/10 2:31 PM, Alexandre Julliard wrote:
Jacek Cabanjacek@codeweavers.com writes:
You can't do that. The default is what's found by 'step (2)' from your description, not any hardcoded path. The version from Gecko package is meant for packaged Wine. You should copy the .cab file to appropriate directory for your own build.
I don't think there would be any harm in trying some global paths even when running from the build tree, so that people can install their distro's wine-gecko package and have private builds take advantage of it. But of course this should be done directly in the code, not by changing the default registry entry.
That's a matter of trivial patch, but what would be the candidate for a path hardcode? '/usr/share/wine/gecko/' seems like the best choice since that's where most distros will install Gecko.
BTW, I don't have much hope that there will be good CAB tool for Linux, so I'd like to get rid of CAB as an archive format for Wine Gecko package in the next release. I think we'd better have the strategy (and maybe code) ready for this now. We need a file format that will be understood by Wine. I can see following options:
- Windows has builtin support for ZIP files. It's hidden behind an obscure APIs, but it's something we could implement and use in MSHTML. - Use .tar.gz files. We already use zlib in Wine, we could use it in MSHTML. tar format is simple enough to implement its custom handling. - Any other idea?
Do you have any opinion?
Thanks, Jacek
On 10/01/2010 06:53 AM, Jacek Caban wrote:
- Windows has builtin support for ZIP files. It's hidden behind an obscure
APIs, but it's something we could implement and use in MSHTML.
- Use .tar.gz files. We already use zlib in Wine, we could use it in MSHTML.
tar format is simple enough to implement its custom handling.
- Any other idea?
Do you have any opinion?
Tarballs been always the de facto standard in *NIX world. It would be nice to use that.
You could even rely on availability of the command line tools (gzip and tar) to extract gecko files. And packagers can make sure Wine depends on them).
Vitaliy.
Jacek Caban jacek@codeweavers.com writes:
That's a matter of trivial patch, but what would be the candidate for a path hardcode? '/usr/share/wine/gecko/' seems like the best choice since that's where most distros will install Gecko.
I'd say try $datadir and then /usr/share.
- Windows has builtin support for ZIP files. It's hidden behind an
obscure APIs, but it's something we could implement and use in MSHTML.
- Use .tar.gz files. We already use zlib in Wine, we could use it in
MSHTML. tar format is simple enough to implement its custom handling.
- Any other idea?
A self-extracting zip may be an option too, not sure how easy they are to create on Linux. And while you are making changes, adding a checksum would be a good idea.
A more ambitious approach would be to define a generic "Wine add-ons" mechanism that could also be used for Mono. This would avoid having detailed knowledge about file formats and download URLs spread around in various DLLs. Maybe this could go in the appwiz control panel, with a nice UI showing which add-ons are installed.
On 10/1/10 4:25 PM, Alexandre Julliard wrote:
Jacek Cabanjacek@codeweavers.com writes:
That's a matter of trivial patch, but what would be the candidate for a path hardcode? '/usr/share/wine/gecko/' seems like the best choice since that's where most distros will install Gecko.
I'd say try $datadir and then /usr/share.
OK, that's what my patch does.
- Windows has builtin support for ZIP files. It's hidden behind an
obscure APIs, but it's something we could implement and use in MSHTML.
- Use .tar.gz files. We already use zlib in Wine, we could use it in
MSHTML. tar format is simple enough to implement its custom handling.
- Any other idea?
A self-extracting zip may be an option too, not sure how easy they are to create on Linux.
I like the idea. I guess we'd want zip files to be PE, as they are more portable for us. I haven't found such tool after a quick search. p7zip can create self-extracting 7z files (I guess format doesn't really matter as long as it's self-extracting), but only for an architecture it's built on, which would be Linux in our case. However, it should be possible to patch p7zip. All the coded needed for this is in place, we'd just have to teach it to choose architecture in runtime instead of build time and teach it about mingw.
And while you are making changes, adding a checksum would be a good idea.
It was always the plan, but never important enough. I will add it together with other changes.
A more ambitious approach would be to define a generic "Wine add-ons" mechanism that could also be used for Mono. This would avoid having detailed knowledge about file formats and download URLs spread around in various DLLs. Maybe this could go in the appwiz control panel, with a nice UI showing which add-ons are installed.
Sounds like a great idea. Cleaning up Gecko install process is a step in this direction. It would also require changing Vincent's plans of not providing our Mono builds.
Thanks, Jacek
On 10/01/2010 07:25 AM, Alexandre Julliard wrote:
Jacek Caban jacek@codeweavers.com writes:
That's a matter of trivial patch, but what would be the candidate for a path hardcode? '/usr/share/wine/gecko/' seems like the best choice since that's where most distros will install Gecko.
I'd say try $datadir and then /usr/share.
I would add /usr/local/share in between those two. Distro packages are supposed to go into /usr, but non distro packages go to /usr/local (eg where make install will put things). So you might want a gecko different from the distro provided one that you built yourself, for instance, but also to have it system wide.
On 10/2/10 4:19 PM, Scott Ritchie wrote:
On 10/01/2010 07:25 AM, Alexandre Julliard wrote:
Jacek Cabanjacek@codeweavers.com writes:
That's a matter of trivial patch, but what would be the candidate for a path hardcode? '/usr/share/wine/gecko/' seems like the best choice since that's where most distros will install Gecko.
I'd say try $datadir and then /usr/share.
I would add /usr/local/share in between those two. Distro packages are supposed to go into /usr, but non distro packages go to /usr/local (eg where make install will put things). So you might want a gecko different from the distro provided one that you built yourself, for instance, but also to have it system wide.
That's what $datadir is for. If you install your build in /usr/local, it will use /usr/local/share first, then /usr/share (after committing the patch).
Jacek
-
Alexandre Julliard -
Austin English -
GOUJON Alexandre -
Jacek Caban -
Scott Ritchie -
Vitaliy Margolen