HH Info

6/9/2014 - At the time of writing MS HTML Help (.chm) is the only choice for general help. All other help systems rely on Visual Studio or Windows 8+ being installed (where no standalone installer is available).

HTML Help requires ANSI HTML files which makes translation tedious. IE. You must edit and compile say Japanese help on a Japanese Windows machine or change the Windows regional settings to Japanese.

For more info on MS Help systems see http://mshelpwiki.helpmvp.com/mshelp | http://www.helpmvp.com/MVP-Info/history

We no longer track changes to HTML Help.

MS HTML Help Home Page:

Download HTML Help Workshop. View API documentation. http://msdn2.microsoft.com/en-us/library/ms670169.aspx

Back To Top

HHUPD.EXE

Hhupd.exe installs the HTML Help runtime files plus language DLLs. Hhupd.exe is also included with HTMLHelp.exe (Workshop installer).

Hhupd.exe does not work on newer operating systems such as Win ME, Win 2000, Win XP, Win Vista etc since HTML Help is now part of the Operating System and can only be upgraded by official updates and service packs.

HH.EXE is not usually changed except for making the version number the same as Hhctrl.ocx.

** Later versions of HH are difficult to list since build numbers different between operation systems.

Back To Top

Prior to HTML Help 1.30 we had a different hhupd.exe and thus hhctrl.ocx for each of the 28 foreign language installs. With 1.30 we now have one hhupd.exe that installs one ocx but 28 language dlls. After installing 1.30 you will find hhctrl.ocx in the Windows System folder as before, but now below the system folder is another folder called \mui which contains all the locale folders. Each locale folder contains a language resource DLL called hhctrlui.dll.

These locale folders are named using the hex representation of that locale's Locale ID (LCID). Thus the English locale's folder is named 409, the German locale's folder is named 407, the Japanese locale's container 411, and so on.

Example: Windows 95/98

\windows\system\mui\409\hhctrlui.dll

Mui I assume stands for Multilingual User Interface.

Note: You can always right-click a DLL and select properties to check version and language details.

When the HtmlHelp API (hhctrl.ocx) is loaded it gets the current locale and loads the resources from the appropriate locale folder. If the folder does not exist it simply defaults to the English resources found in the ocx. So if DLLs are not installed hhctrl.ocx still work and display English.

The immediate advantage for us as developers is obvious. We now have only one install file to download and distribute. We no longer have to detect the Windows O/S language and install the correct hhupd.exe.

Language & LCID ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 0401 Arabic 0403 Catalan 0404 Traditional Chinese 0405 Czech 0406 Danish 0407 German 0408 Greek 0409 English ** 040A Spanish 040B Finnish 040C French 040D Hebrew 040E Hungarian 0410 Italian 0411 Japanese 0412 Korean 0413 Dutch 0414 Norwegian (Bokmal) 0415 Polish 0416 Portuguese (Brazilian) 0419 Russian 041B Slovak 041D Swedish 041F Turkish 0424 Slovenian 042D Basque 0804 Simplified Chinese 0816 Portuguese (Standard)

** Note that HH1.3 always reads English resource strings from the OCX not from the DLL as it should.

PS. I notice that installations of HH that come with Windows 2000 and XP come only with the required language resource DLL files. Hhupd.exe wont install on these systems. On older systems Hhupd.exe 1.3x will install all language resource DLLs.

Back To Top

Example 2:

Alternatively you can enable sites by using IE Security Zones.

First set the following registry item to enable Hhctrl ActiveX to work in a Zone.

Default value for MaxAllowedZone = 0 (allow Local machine zone only)

Thus if http://helpware.net was part of your companies local Intranet you would do the following:

Better still your network administrator could push down the settings to all machines.

Since http://helpware.net is a web site on the Internet you would do the following:

Why don't my settings work?

1. Check that all URLs have a trailing slash
2. http://helpware.net/
4. When adding a site to reg item "UrlAllowList" make you add all sub-domains used.
5. "UrlAllowList"="http://helpware.net/;http://www.helpware.net/"
7. When adding a site to an IE Security Zone, again add all sub-domains used.
8. Note: IE Security Zone lists allow the form http://*.helpware.net/ (so only one entry is required).
10. After you change a setting and before you test, first shutdown all instances of IE to clear any memory effects.

Feedback from user Frank Palinkas in South Africa - Thanks Frank

Hi Rob and Team,

Thought I’d post this to let you know of a serious problem I and several others discovered after installing Windows Server 2003 Service Pack 1, on a Windows 2003 Server, where .chm’s are stored for viewing and downloading through an Intranet.

1. After Windows Server 2003 SP1 is installed on a Windows Server 2003 machine, if a user opens a .chm sitting on that Server, they will receive an “Action cancelled” error in the .chm’s viewer frame. The TOC and Index display normally.
2. No matter which topic the user tries to view using the TOC or Index, an “Unable to open this web page” message appears in the .chm viewer frame.

CAUSE: Windows Server 2003 SP1 disables all Internet Security zones except the Local Machine zone. In this case, the Local Intranet zone blockage was causing the problem.

KB896054 gives a workaround.

This Microsoft Knowledge Base Fix requires the Windows Server 2003 SP1 machine to be adjusted from its Registry. NOTE: You cannot solve this problem by adjusting the Security Zones feature in Internet Options in Internet Explorer. It MUST be done via the Server’s Registry.

Applies to W2003 SP1 & WinXP SP2. See KB896358.

KB902225 gives the following workaround:

To resolve this problem, click to clear the Always ask before opening this file check box in the Open File-Security Warning dialog box, and then click Open. Alternatively, right-click the file that you want to open, click Properties, and then clickUnblock.

What version of Internet Explorer and HTML Help were shipped with Windows.

Internet Explorer is embedded in the HTML Help viewer and required to view content.

Early version of HH required you to install IE version 3.0 or greater. IE4 was required for DHTML & advanced scripting, and IE5 for XML support.

Modern Windows Operating Systems include Internet Explorer.

From http://support.microsoft.com/default.aspx?scid=KB;en-us;q164539

Note1: Early versions of IE did not have a 4th version number, so be careful when reading version info from Shdocvw.dll that you don't turn say 4.70.1155 into 4.70.0.1155.

Note2: Notice that IE2 (shipped with NT4) displays the internal version number (4.4.0.520) in the about box. This can create some confusion as NT4 customers incorrectly report "Yes I do have Version IE4".

Back To Top

It may help to compare the HH files with WinHelp files.

Back To Top

Creating an install program to get HTML Help on a customers machine can be tricky.

HHUPD.EXE

hhupd.exe is a free download from the MS Web. Use it to upgrade or install HTML Help on a customer's machine. HH requires that IE3 or greater be install first. HH actually uses the IE layout engine. The IE browser executable itself is not required.

To install quietly use the switches "/r:n /q:a"

For hh < 1.3, for non-english PCs your installation program should detect and install the appropriate language version of hhupd.exe.

Installing HHUPD.EXE

Check the version of HH before installing. Version info can be read from file hhctrl.ocx.

hhupd.exe installs the ocx into the windows system folder. Note however that the ocx could also be installed in the windows ocx cache via an ActiveX download from the web. So the safest way to locate hhctrl.ocx is via the registry. The full path to hhctrl.ocx can be found in the default value of registry key:

"HKEY_CLASSES_ROOT\CLSID\{adb880a6-d8ff-11cf-9377-00aa003b7a11}\InprocServer32".

Installing Internet Explorer

Before checking for HH you should first check if IE is installed. Minimal requirement for HH is IE3.0 (not 3.02 as some think). If your help uses DHTML or XML then obviously IE4 or IE5 will be required.

The version of the installed IE can be read from the file Shdocvw.dll found in the windows system directory.

See the IE version information above.

IE Component Install

The easiest why to distribute IE to your HTML Help customers is under the IEAK Independent Software Vender (ISV) license. No reporting or strings attached. Fill in the registration form, download the required IE5 components and package it up. You must install IE5 in "passive" also known as "silent" mode which means no IE setup dialogs are to be shown.

License and registration: https://ieak.microsoft.com/en/License/isvlicense.asp

Note: The component install must be run in silent mode. This does not mean you try and hide the fact that you are updating their operating system. The IE browser is installed however the silent install mode does not create program folders and shortcuts. Netscape will remain the default browser if it was the default browser before the install.

IEAK IE5 ISV license agreement went public: 30-Jun-1999

For more info and fee silent installers go to

http://www.mvps.org/htmlhelpcenter/iesilent.htm

Reading Version Info

Programmers can read file version info using the functions GetFileVersionInfo() and VerQueryValue(). The version info is stored in dwFileVersionMS & dwFileVersionLS items of structure VS_FIXEDFILEINFO.

For download info please see the Web Links Page.

Back To Top

** The following discussion is pre-MS Help 2.0 collections.

There is a lot of interest in VS6 collections at the moment so here are some basic facts.

MSDN and MMC needed a way to "snap in" a CHM module at install time. So they built support for collections into HTML Help.

Each CHM should be compiled with binary toc, binary index and no merge information. The .COL file defines how the CHM modules are merged together at run time. HH API and HH.EXE can open COL files like a CHM.

Collections are not an open system at the moment. There is no documentation available.

The binary TOC used an MSDN collection is not compatible with some features of HTML Help 1.x. These include:

• "use folders instead of books".
• Custom TOC icons.
• Does not supports styles - things like single-click opening one book and automatically closing another book.
• Standard merge.
• Information types.

However, binary TOC does allow you to add browse buttons to the top of your HH window. See htmlhelp.h for button Ids. The current TOC loaded in the HH window is used as the browse sequence.

A recent post from Jeremy Griffith shows us how to make HH Workshop show a few extra settings such as the "Create .CHI Index file" -- In the Workshop Open dialog, type "I'm MSDN" (without quotes) and click Open. You also get Window Definition toolbar settings "Next, Previous, Zoom".

If you want to add your help into VS6/MSDN collections you do so at your own risk.

For more info see: http://www.codeguru.com/

• Guide to MSDN Collection Integration - by Kirk Stowell
• MSDN Help Integration - by Shannon McCoy

Back To Top

Information on storage files and Workshop files.

Changes since HH 1.2x

MS HTML Help Web Site

New web site

http://msdn2.microsoft.com/en-us/library/ms670169.aspx

http://msdn2.microsoft.com/en-us/library/ms670169.aspx

Documentation Set

api.chm - Updated

hhaxref.chm - No change

htmlhelp.chm - Updated

viewhlp.chm - No change

A Japanese version of the documentation is also available.

Changes to Workshop

Workshop contains minor fixes plus no more 3001, 3003, 3005 warnings and no more crashes caused by spaces in URLs in large indexes or TOCs.

3001 - The file "%s" has a link to a non-existent file: "%s".

3003 - The HTML tag "%s" has invalid characters appearing before the closing angle bracket: %s

3005 - The HTML end tag "%s" has invalid characters before the closing angle bracket (>).

readme.txt -- Woops!! - An empty file.

The duplicate files htmlhelp.lib and htmlhelp.h in the root have been removed. Readme.htm has been replaced by readme.txt.

\redist\hhupd.exe -- Take care. Workshop installer appears to be using a new installation program which is not overwriting any previous versions of \redist\hhupd.exe. Several people have installed workshop over old installations and have noted that \redist\hhupd.exe remains at V1.2.

30-Jan: I just did a folder compare with a file sync program. Hhupd.exe is not the only problem. When the new install program installs over the top of a 1.2 workshop installation it also neglects to update 16 support DLLs in the HTML Help Workshop folder. So best to do a clean installation.

BTW: Great shareware program. Download FileSync from http://www.fileware.com/. Pointed it at my pure 1.3 workshop install folder and my overwritten folder. It showed me the 16 DLLs plus HHUPD.EXE that were different in date then allowed me to press a button and update the DLLs in my overwritten folder. Nice.

Changes to hhupd.exe

The 28 individual international versions of hhupd.exe have gone. Now there is only a single hhupd.exe that installs HTML Help runtime files plus 28 language resource DLLs (see below).

HH 1.3 now writes hh.dat (window position info etc) to the folder %windir%\Application Data\Microsoft\HTML Help\

1. Workshop WinHelp to HTML Help convert does not working under Japanese Windows. Workshop says that a DLL is missing. Fix: Use 1.2x Workshop for now. [Status: Reported]
2. Some people see font changes happening in the TOC and Index tabs when viewing old and new CHMs under HH 1.3. [Status: Watching]
3. Installing over old workshop does not updated some HTML Help Workshop folder DLLs and HHUPD.EXE. Fix: Install to new folder. [Status: Reported]
4. TOC Sync problem in merged help. I have several CHMs merged. The Master CHM is the host and has a Topic "Fred.htm". All my other TOCs used by other CHMs include a link to Fred.htm as well. EG. its:master.chm::/fred.htm. So in my merged TOC I have several TOC items linking to a single Fred.htm in master.chm. The problem is this -- When I click on any Fred.htm TOC link the TOC syncs to the next Fred.htm in the in the merged TOC. The TOC pointer should obviously stay where it was clicked. Note: When you click the TOC Fred.htm item (original) in the master TOC all is OK. Problem in 1.2x as well. [Fix: Don't Merge]
   1. Since upgrading to HH1.3 yesterday, my Related Topics buttons, which were Alinks displayed on a pop-up menu, are now displaying in the Topics Found dialog box -- Angi Phillips
      1. Ralph Walden: I asked Shane about this and he responded with:
      2. "This will happen if the language of the OS doesn't exactly match the language of the chm. The problem is that in some cases this mismatch causes garbage in the menu (if the language of the chm can't be displayed in the font the system uses for menus), so we fall back to the Topics Found dialog, in which we can set the font."

Note: A newer version of HH is now available which fixes some of the above bugs. Unfortunately Windows 2000 system files can only be updated via an official W2K service pack.