HtmlHelp status, winecfg and SoC proposal

[Jacek Caban]

Hi Paul,

Paul Wise wrote:
>> Paul seems to be excited about Wine, so hhm relicensing should sound OK 
>> for him, IMHO.
>>     
>
> I've previously offered to relicence the hhm code for inclusion in both
> chmlib and libmspack, but it seems neither project took up this offer. I
> don't think the hhm code belongs anywhere other than in one of them. The
> current version was more of a proof-of-concept, I wanted to push the
> code into a chm reading/writing library. IIRC, wine's itss.dll uses
> libmspack, so perhaps it should go there?
>   
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.
> 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...
> I've also previously (2003) pointed wine-devel at chmspec and offered to
> relicence chmdeco code for use in a wine version of hh.exe. No-one was
> interested though, saying that a CHM viewer was already implemented and
> then deteriorating into a thread about which browser to embed and
> forking KHTML and Mozilla and so on.
>   
Things have changed. Now Wine has MSHTM/WebBrowser implementation that
make it possible to support HtmlHelp.
>   
>> But only if proved it isn't breaking M$ licences [2], right?
>>     
>
> The licence says this:
>
>   
>> * Limitations on Reverse-Engineering, Decompilation, and Disassembly.
>> You may not reverse- engineer, decompile, or disassemble the SOFTWARE
>> PRODUCT, except and only to the extent that such activity is expressly
>> permitted by applicable law notwithstanding this limitation.
>>     
>
> As written in the chmspec colophon, I didn't do any disassembly of
> Microsoft stuff, only black-box format discovery. Mainly this was by
> sending different inputs to Microsoft's hhc and observing the output, as
> well as looking at existing samples of CHM files. I imagine that is
> probably "reverse-engineering" according to Microsoft (although they
> haven't contacted me at all, so maybe not).
>
> http://chmspec.nongnu.org/latest/Colophon.html
>   
That's fine for sure. Thanks for your work, it was very helpful to me!
> Frankly I haven't done anywhere near enough reverse engineering of the
> internal CHM formats to even be close to thinking about implementing a
> full-blown CHM compiler that would create correct CHMs. There is enough
> info for CHM readers like chmdeco, xCHM and so on to be written, but not
> for compilers. Patches to chmspec are welcome though :)
>   
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.
> Why does wine want a CHM compiler anyway? Can't Microsoft's one be used?
> Microsoft's one isn't distributed with the OS anyway.
>   
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.

Thanks,
    Jacek