Whither WinHelp (and WinHelp 2000)?

In the mid-‘80s, online help authors had a choice of many tools – Views, Window Book, Black Magic, etc. Each tool had an authoring module, costing about $500, and a user module, costing about $50 per user. The latter kept the market small because it was expensive to provide online help for each member of a large user community at $50 a pop.

Microsoft’s release of Windows Help, or WinHelp as it become known, in the late ‘80s changed this. It killed the older authoring tools, pushed hypertext into the mass market, and laid the foundation for online help as it exists today. WinHelp was unofficially terminated in ’97 when Microsoft released HTML Help. It’s now, apparently, been officially terminated with the release of Vista which, officially, no longer supports WinHelp. But dead or not, WinHelp is still used by many firms that, for various reasons, have not yet moved to HTML or XML.

So What is WinHelp?

WinHelp files are written in a format called RTF (Rich Text Format). (HTML Help uses, not surprisingly, HTML.) The RTF files are processed – “compiled” – into the finished output that’s distributed to users.

In the first version of WinHelp, the output was one file with an .hlp extension that contained all the topics and some minimal navigation features. Later versions of WinHelp added a second file with a .cnt extension that added table of contents, index, and search tabs. Users viewed the whole thing with a help mini-browser made up of one file – winhelp.exe, later winhlp32.exe – that came with Windows.

WinHelp’s authoring module was effectively free since authors could type the text and codes in Windows Notepad and use a free compiler from Microsoft to create the output. The user module was free since the winhelp.exe or winhlp32.exe file was bundled with Windows. The older hypertext systems couldn’t compete and either went out of business or went into niche markets.

Although authors could hand-code in Notepad, this was boring and a rich source of typos. Early authors created macros to speed up the work, and it wasn’t long before commercialized versions appeared – Doc-To-Help in ’91, RoboHelp and others soon after. The help authoring tool, or HAT, market was born.

Most early HATs were really Word plug-ins. They used Word’s features to create the content and add codes in regular .doc files, then converted the files to .rtf for compilation. In theory, authors could use any word processor to do this but Word was the easiest. As a result, authors who used other word processors, like Ami Pro, Manuscript, or WordPerfect for hard-copy but needed to create online help as well often migrated to Word, which hurt the other word processors’ sales.

WinHelp’s Output Structure

When users opened an early WinHelp file, they saw one window containing the help’s “home page”. Here’s an example, a WinHelp file that I wrote in the mid-90s as an introduction to graphics for new online authors.

Note that there’s no table of contents, index, or search tab. To see them, users clicked the appropriate button in the “button bar” below the menu. This opened a separate “navigation” window containing the table of contents, index, and search tabs. Separate navigation and content windows made sense early on, when no one knew the best way to design help, but soon proved inefficient because users had to actively reopen the navigation window in order to use it, a big drawback.

Another drawback was the fact that a typical WinHelp project might pack several hundred topics into one Word file. This caused two problems. First, a Word file containing the equivalent of several hundred pages of material might take twenty minutes to open. It was also difficult to manipulate individual topics.

Another drawback, though not obvious at the time, was WinHelp’s use of macros to control many of its features. Today’s security concerns didn’t exist in the early ‘90s but, for companies still using WinHelp today, the macros must be a concern.

Another drawback is the shrinking pool of authors who can create WinHelp. The tools that date from the early days of help, like Doc-To-Help and RoboHelp, were originally created for WinHelp and only moved to HTML later. So these tools still support WinHelp; RoboHelp for Word, for example, is the original RoboHelp of 1991, albeit much upgraded. But fewer and fewer authors know how these tools work or understand the details of WinHelp projects, like the +, $, and K and other symbols at the top of each topic. So companies that still use WinHelp are at risk of losing the ability to maintain their own help systems.

Finally, as technical communication continues moving into a web model, WinHelp can’t support the new features coming online. And it just looks old…

What About WinHelp 2000?

When Microsoft released HTML Help in ’97, it combined WinHelp’s separate content and navigation windows into one “tri-pane” window, as shown below.

To ease the shift to HTML, eHelp created a RoboHelp output that bridged HTML Help and WinHelp. It kept the WinHelp code but modified the look of the output to sort of resemble HTML Help. The result was WinHelp 2000, below. (The example is from RoboHelp for Word.)

It looks sort of like HTML Help in that it shows the content and navigation panes together – the “tri-pane” model. This is controlled by enabling a WinHelp 2000 feature and distributing a WinHelp 2000 plug-in with the .hlp and .cnt files. But it’s still WinHelp, and thus has all the disadvantages of WinHelp.

I’ll sum up by saying that WinHelp has a long and distinguished history and that it created much of today’s online help authoring world. But its end is in sight and it’s getting to be time to move on.