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