On Tue, 2007-03-13 at 20:13 +0100, Jacek Caban wrote:
Yes, it should go to itss.dll to support writing mode in storages. But we can't use itss in hhc replacement as it has to be useful for Wine compilation. It means that we need plain UNIX app. That's the code duplication I wrote about.
AFAIK, itss.dll doesn't know anything about internal CHM formats, it just deals with the InfoTech Storage format (container format for CHMs), so no need for code duplication at all.
For a wine version of hha.dll/hhctrl.ocx and so on, there is always the possibility of creating a libhtmlhelp or something like that that can read and write the internal CHM formats, that uses a write-enabled libmspack or chmlib. Then use that library in wine's version of hha.dll/hhctrl.ocx/etc as well as the compiler, no need for code duplication at all. The current chmdeco code could form the initial decoding part of that library and write support could form around that.
Also, if it does get included, I'd *STRONGLY* request/suggest that the code be modified to also include a README.hhm.txt (or similar) file saying something like "This file was not produced by Microsoft's HtmlHelp compiler, it may have incompatibilities preventing it from being used on Windows." I think this is an important inclusion in any non-MS compiler, one which I haven't got around to adding to hhm yet.
Then we could add such README about whole Wine :-) Our aim is to improve things to be useful, not to write something and tell users to not use it because it sucks...
To be clear, this file would not be visible to users unless they unpack the files with extract_chmLib or istorage.exe or something. The idea was to document the fact that those files are non-Microsoft, so if there are issues with those files later, the person investigating those issues will immediately know that the file is non-Microsoft and then be able to direct any bug reports to the appropriate place. So it wouldn't be telling users not to use it, it would be telling recipients of hhm-created files where to go in case of problems.
Things have changed. Now Wine has MSHTM/WebBrowser implementation that make it possible to support HtmlHelp.
That is good to hear.
I have to disagree. Surely it's enough to implement a compiler that will work with Wine's HtmlHelp. Also it should be possible to implement a compiler that will work with native hhctrl.ocx. Even if not everything is documented, dummy values should be good enough for most uncovered things. Also more things that will be needed may be discovered during SoC.
I suppose it may be possible, I'd still suggest adding a README.hhm.txt to CHM files produced by hhm to warn that it may still be using dummy values. If you want to implement that I'm happy to provide explanations of any unclear bits in chmspec and accept chmspec bugs or provide other help on the project.
If we want to include chm files to Wine (like help for winecfg) we have to be able to compile them. Perhaps some apps ported with winelib would benefit from chm compiler.
Ok, that makes sense. I don't really understand the desire to use CHM files in Wine, that isn't relevant to this conversation though.