HtmlHelp status, winecfg and SoC proposal

Paul Wise pabs3 at bonedaddy.net
Mon Mar 5 22:59:16 CST 2007


[please CC me on replies, I'm not subscribed to wine-devel]

On Mon, 2007-03-05 at 19:30 +0200, Saulius Krasuckas wrote: 

> * On Sun, 4 Mar 2007, Jacek Caban wrote:
> > HtmlHelp maker (hhc, see [1]) doesn't create internal files (parts of 
> > chm that describes stuff like index or default topic) and it's GPLed so 
> > it's useless for Wine (unless author would relicense it for us). 
> 
> Quoting Paul Wise resume from the [1]:

Eeep, haven't updated that in years. Just deleted it and replaced with a
link to my homepage.

> 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?

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. 

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.

> 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

> Nice idea.  Maybe even Paul himself would join that, as he states in his 
> blog [3] he needs "Employment, bux, moolah, work".
> (I've Bcc-ed Paul in his message)

I'm not a student, so I'm not eligible to implement that project as part
of the SoC. If people want to pay me privately, that would be great
since I'm in need of work at the moment. I'm happy to answer questions
that come up in the SoC in relation to chmspec though.

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 :)

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.

Also, Matthew's ITSF (the container format built and read by itss.dll)
spec has a few bugs that I did a bit of work on while I was sailing,
haven't done anything recently on them though, I'm hoping to get to that
soon.

Also, there is some bug in the chmlib/hhm/lzx_comp combination that
causes xCHM and other chmlib based CHM viewers to crash when accessing
CHMs created using hhm (linked against lzx_comp), this needs
investigating and hhm/lzx_comp should not be used until it is.

-- 
bye,
pabs

http://pabs.zip.to
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070306/1b2c7eeb/attachment.pgp


More information about the wine-devel mailing list