HtmlHelp status, winecfg and SoC proposal

[Paul Wise]

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.

-- 
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/20070314/5ebfd473/attachment.pgp