Hubbry Logo
logo
WinHelp
Community hub

WinHelp

logo
0 subscribers
Read side by side
from Wikipedia
WinHelp
Filename extension
.hlp
Internet media typeapplication/winhlp
Magic number3F 5F 03 00[1]
Developed byMicrosoft
Initial release1990
Extended fromRTF
StandardNo
Microsoft WinHelp
DeveloperMicrosoft
Operating systemWindows Vista, Windows 7, Windows 8, Windows 8.1
Included withWindows 3.0, Windows 95, Windows XP
SuccessorMicrosoft Compiled HTML Help
TypeHelp system

Microsoft WinHelp is a proprietary format for online help files that can be displayed by the Microsoft Help browser winhelp.exe or winhlp32.exe. The file format is based on Rich Text Format (RTF). It remained a popular Help platform from Windows 3.0 through Windows XP. WinHelp was removed in Windows Vista purportedly to discourage software developers from using the obsolete format and encourage use of newer help formats. Support for WinHelp files would eventually be removed entirely in Windows 10.

History

[edit]
  • 1990 – WinHelp 1.0 shipped with Windows 3.0.
  • 1995 – WinHelp 4.0 shipped with Windows 95 / Windows NT.
  • 2006 – Microsoft announced its intentions to phase out WinHelp as a supported platform. WinHelp is not part of Windows Vista out of the box. WinHelp files come in 16 bit and 32 bit types. Vista treats these files types differently. When starting an application that uses the 32 bit .hlp format, Windows warns that the format is no longer supported. A downloadable viewer for 32 bit .hlp files is available from the Microsoft Download Center.[2][3] The 16 bit WinHelp files continue to display in Windows Vista (32 bit only) without the viewer download.
  • January 9, 2009 – Microsoft announced the availability of Windows Help program (WinHlp32.exe) for Windows Server 2008 at the Microsoft Download Center.[4]
  • October 14, 2009 – Microsoft announced the availability of Windows Help program (WinHlp32.exe) for Windows 7[5] and Windows Server 2008 R2[6] at the Microsoft Download Center.
  • October 26, 2012 – Microsoft announced the availability of Windows Help program (WinHlp32.exe) for Windows 8 at the Microsoft Download Center.[7]
  • November 5, 2013 – Microsoft announced the availability of Windows Help program (WinHlp32.exe) for Windows 8.1 at the Microsoft Download Center.[8]
  • July 15, 2015 - Microsoft completely removed Windows Help from Windows 10. Attempting to open a .hlp file just brings users to a help page detailing that it was removed.[9]

File format

[edit]

A WinHelp file has a ".hlp" suffix. It can be accompanied by an optional table of contents (.cnt) file if the help developer created one. When Windows opens a WinHelp file, it creates a .gid file in the same directory or in "%LOCALAPPDATA%\Help", containing information about the .hlp file such as the window size and location. If the user clicks the "Find" tab and enables keyword indexing, Windows creates an index file with a .fts (full text search) extension. Annotations and bookmarks for each Windows help file have the extension ".ann" and ".bmk".

A number of software tools can decompile a WinHelp file into its source documents: HPJ, CNT, RTF, BMP, and SHG. An HPJ file is the project file that is created and edited in the Help Workshop (or a third party help authoring tool). The HPJ contains information about what RTF files to compile into the help, the MAP IDs and Aliases that provide links from a calling application to the help file, and help file appearance (window size, default buttons, color schemes, etc.). The CNT file provides the table of contents for the help file. An SHG file is a "SHED" graphics file that essentially creates an image map of help calls for a graphic file (e.g., a BMP).

A number of tools can read and explore these files. (See, for example, Help to RTF and winhelpcgi.)

Summary on winHelp files
.hlp Description
.hpj project file (plain text?); contains a list of all .rtf files to compile into the .hlp file and some additional information
.cnt Table of Contents (TOC) file.
.rtf actual text content in Rich Text Format-format
.bmp .dib .wmf .shg picture-files in various formats: .bmp or .dib, .wmf .shg
.fts .ftg Full Text Search; used for searching through the text of help documents
.ann file with annotations (plain text?)
.bmk file with bookmarks (plain text?)

Source files and compilation

[edit]

Source files required to compile a .hlp file consist of one or more documents in Rich Text Format and a help project file with the extension .hpj, along with any image files (.bmp, .wmf, or .shg) that are used within the Help file. An optional table of contents file with the extension .cnt can also be created for use with the .hlp file.

Within the .rtf files, topics are separated by page breaks. Each topic has a series of footnotes that contain information for the help compiler:

# footnotes contain the topic ID (used to create links to that topic).
$ footnotes contain the topic name as it displays in the table of contents, index, and other locations.
K footnotes contain keywords for the index.
A footnotes contain See Also keywords.
* footnotes contain build tags.
+ footnotes contain browse sequence information.
! footnotes contain topic entry macros.

Only the # footnote is required. All others are optional.

Text in each topic can contain limited formatting, including bold text, italics, and colors. Superscript and subscript are not allowed. Jumps between topics in the same Help file usually appear in the source document as double-underlined text (green by default, though this can be overridden) followed by a topic ID in hidden text. Popup links appear in the source document as text with a single underline (also green by default) followed by a topic ID in hidden text. (In the .hlp file, the jumps show up as green text with a single underline, and popups show up as green text with a dotted underline.)

Images can be added using codes such as {bmc image.bmp}. Supported image formats include .bmp, .wmf, and .shg (used for image maps, which can contain jumps or popups that are triggered by clicking on specific parts of the image).

After the source files have been created, the help file can be compiled using a WinHelp compiler such as HCW.exe or by using a commercial software program such as RoboHelp or HelpBreeze Archived 2016-01-21 at the Wayback Machine, most of which (included the two cited here) also use hcw.exe as the backend compiler.

WinHelp appearance and features

[edit]

Depending on how it has launched and what settings the Help author chose, a WinHelp file opens either to its default topic, its table of contents, or its index.

A topic in a WinHelp file opens in a separate window, in a size and initial position that the Help author may choose. Users can resize or reposition the window. The Help author can control whether the Help file stores the user's settings between sessions, or always opens in the default size and position.

When a topic is open, a title bar at the top of the Help window displays the topic title. Below that is a row of menus (File, Edit, Bookmark, Options, and Help), which control various aspects of the file. A row of buttons usually appears below the menus. The Help author controls which buttons, if any, appear. Typical buttons include Contents, Index, Back, and Print, along with << and >> buttons to browse through the file. Help authors can also create custom buttons to jump to specific topics or perform other actions.

Below the buttons is the main text area of the window. Typically, the text begins with a heading, often bold or in a larger font than the rest of the text. This heading may sometimes be in a non-scrolling region—an area of the window that does not move up or down via the scrollbar at the side of the window. Non-scrolling regions can only be used at the beginning of a topic. The Help author can control size and background color of a non-scrolling region.

Help authors can also control the background color of the main text area, where the actual text of the topic appears. This text can be formatted and arranged in many ways. Within the text, jumps appear as green text with a single underline. Single-clicking on a jump opens a different topic. Some jumps may open secondary Help windows to display information. Popups appear in the text as green text with a dotted underline. Single-clicking on a popup opens a small window with no menus, buttons, or scrollbars, sized to fit the text. Often, popups provide short definitions of key terms or other supplemental information about the main text. The popup automatically disappears the next time the user clicks or presses a key.

Many, though not all Help topics have See Also jumps at the end of the text. Depending on the Help author's preference, this feature may be a simple list of jumps under the heading See Also, or it may be a small button that, when clicked, brings up a dialog box displaying all the relevant topics. Clicking on the name of a topic in that dialog box then clicking Display opens that topic.

Most Help files also contain a table of contents and an index to help users locate information. These appear in a separate, tabbed window. Clicking on the Contents tab opens the table of contents, in which users can click on headings to see the topics. Often, headings are marked with icons that look like small books and the topics have icons that look like pages. Double-clicking on a topic (or clicking on a topic then clicking Display) opens that topic. Clicking on the Index tab opens the index, which has a typing field and an alphabetical keyword list. Typing in the typing field automatically scrolls the list of keywords to the closest match. Double-clicking on a keyword (or clicking on a keyword then clicking Display) displays the topic associated with that keyword (if only one) or brings up a list of all topics associated with it. The index is important in helping users locate information. Sometimes Help files also have a Find tab, which lets the user search for any word used in the text of the file, not just for keywords.

WinHelp also supports a feature known as context-sensitive help. Context-sensitive help is assistance that is appropriate to where the user is in the software application, and what they are trying to do.

A rather security critical feature is that one can also include a DLL file containing custom code and associating it with WinHelp topics. Effectively this makes .HLP files equivalent to executables.

End of support

[edit]

At the 2006 WritersUA conference, Microsoft announced its intentions to phase out WinHelp as a supported platform. Ted Dworkin (Partner Director of WinHelp Experience) stated, "WinHelp does not meet the code standards established for Vista. These standards include security, reliability, and performance." He went on to say that WinHelp is designed in such a way that, "...we would have to rewrite it from the ground up to meet the Vista code standards. And that approach doesn't make sense given that we have two other Help systems in Vista."[citation needed]

The updated licensing agreement prohibits application developers from packaging the WinHelp libraries with their installers. This means that WinHelp manuals for legacy applications are not readable on a new Windows Vista (or higher version) installation. To read them, the end-user must obtain the 32-bit WinHelp viewer from Microsoft's website and manually install it.[10]

In Windows 10 and later, Microsoft does not offer a WinHelp viewer for the operating system. The last version of Windows on which it was possible to open and read WinHelp files, using an official downloadable component by Microsoft, is Windows 8.1. The open-source version of winhlp32 from Wine also works on Windows 10. It is included as part of WineVDM. Also on Windows 10 WinHelp works with winhlp32.exe from older version of Windows.

Other documentation file formats

[edit]

Although documentation can be maintained entirely in a vendor-specific presentation format such as WinHelp, it is more often the case that documentation must be published in multiple presentation formats at once: Microsoft Compiled HTML Help (CHM), WinHelp, HTML pages, Java Help, PDF, etc. It would be very expensive and error-prone to maintain each format separately.

For this reason, authors often maintain documentation in an industry-standard, vendor-neutral authoring format—such as DocBook or FrameMaker—that can be used to generate several different presentation formats (including WinHelp).[citation needed] Various presentation files thus produced (with WinHelp or other tools) contain consistent content because they were generated from the same source.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia
from Grokipedia
WinHelp is a proprietary online help system developed by Microsoft for displaying context-sensitive documentation in Windows applications, utilizing compiled .hlp files viewed via the WinHlp32.exe program.[1][2] Introduced in 1990 alongside Windows 3.0, WinHelp represented an early form of digital assistance, enabling users to access help content directly from within software without relying on physical manuals; the term "online" here referred to content immediately available on the local computer, predating widespread internet connectivity.[3][4] The system supported rich features such as hyperlinks for navigation, embedded graphics, pop-up windows, searchable indexes, and even executable macros that could invoke application functions, making it a versatile tool for developers in the pre-web era.[1][4] Based on the Rich Text Format (RTF) with proprietary extensions, .hlp files functioned similarly to self-contained executables, allowing interactive elements but also introducing security risks by permitting arbitrary code execution.[5][4] WinHelp served as the default help format through Windows XP but was deprecated by Microsoft in 1996 in favor of HTML Help (.chm files), with full removal from the operating system core beginning in Windows Vista (2007) due to outdated security standards and to reduce the attack surface.[5][4] For compatibility in later versions like Windows 7, 8.1, and 10, Microsoft provides WinHlp32.exe as a restricted download, limiting its functionality to viewing only and disabling macros to mitigate vulnerabilities.[2][5]

Overview

Definition and Purpose

Microsoft WinHelp is a proprietary file format developed by Microsoft for creating and displaying online help files in Windows applications, utilizing the .hlp extension and viewed through the winhelp.exe or winhlp32.exe executable.[6][1] The primary purpose of WinHelp is to provide embedded, context-sensitive assistance to users within software, featuring hyperlinked topics, searchable indexes, and navigational elements that enable quick access to explanatory content without leaving the application.[7][6] This format supports interactive elements such as pop-up definitions, multimedia integration, and structured contents, facilitating efficient user support in graphical user interfaces. As an RTF-based system, WinHelp represents a proprietary approach to "online yet offline" documentation, meaning help content is stored locally on the user's machine for immediate availability, independent of network connections.[8][3] Introduced with Windows 3.0 in 1990, it was designed to supplant static text-based help files like .txt or .doc formats with dynamic, windowed displays that leverage the operating system's graphical environment for enhanced interactivity.[3][4]

Role in Windows Documentation

WinHelp served as the primary help system for Windows applications throughout the 1990s and into the early 2000s, functioning as the standard mechanism for delivering context-sensitive assistance directly within software interfaces. It was deeply integrated into Microsoft applications such as Word and Excel, where pressing the F1 key would invoke WinHelp to display targeted help topics relevant to the active context, such as specific menu options or dialog elements. This integration extended to third-party software developed for the Windows platform, ensuring a uniform user experience across diverse programs by leveraging the built-in WinHelp viewer (winhelp.exe or winhlp32.exe) to handle .hlp files.[4] The format's significance lay in its ability to provide rich, multimedia documentation entirely offline, without requiring an internet connection, which was particularly valuable in an era when web-based resources were not yet ubiquitous. WinHelp supported embedded graphics, animations, hyperlinks, and pop-up windows, allowing developers to create interactive and visually engaging help content that went beyond plain text. Additionally, it enabled customization through DLL extensions, permitting applications to implement bespoke behaviors, such as specialized navigation or integration with application-specific features, enhancing the flexibility of help delivery.[4][9] WinHelp's widespread adoption profoundly influenced software user experience (UX) by establishing a consistent, accessible framework for on-screen assistance that minimized disruptions during task completion. It dominated the Windows help ecosystem until the early 2000s, becoming ubiquitous in applications from the Windows 95 and NT eras, where it effectively supplanted the need for extensive printed manuals by consolidating comprehensive guidance into a single, searchable digital file. This shift promoted more efficient documentation practices and improved usability for end-users navigating complex software environments.[4]

Historical Development

Origins and Early Adoption

WinHelp originated as a Microsoft initiative to develop an interactive online help system tailored for the graphical user interface of Windows 3.0. Beginning in the late 1980s, Microsoft engineers worked on the project to move beyond the constraints of command-line and plain-text help utilities prevalent in earlier MS-DOS environments, focusing instead on a format that supported hypertext navigation, embedded graphics, and contextual assistance within a point-and-click paradigm.[4] Key figures in its development included Leo Notenboom, who led the WinHelp 3.0 effort, and Floyd Rogers, who created the initial version starting in the early 1980s with substantive work from 1987.[10] This effort aligned with the broader redesign of Windows into a more accessible operating system, where help content needed to integrate seamlessly with visual elements like windows, icons, and menus.[11] The primary motivation for WinHelp was to overcome the inadequacies of static, linear documentation in a graphical operating system, enabling features such as clickable links to related topics, searchable indexes, and multimedia integration that mirrored the interactivity of the desktop environment. Drawing inspiration from Apple's HyperCard—a pioneering hypermedia tool for the Macintosh—Microsoft aimed to create a standardized, lightweight help viewer that could be bundled with applications and the OS itself, fostering easier user onboarding for GUI-based software.[4] By 1989–1990, during the final phases of Windows 3.0 development, the system had evolved into a proprietary format using Rich Text Format (RTF) as its base, compiled into compact .hlp files for efficient distribution on floppy disks.[12] WinHelp made its public debut on May 22, 1990, alongside Windows 3.0, powered by the winhelp.exe executable that served as the dedicated viewer for rendering help content.[13] This launch marked a pivotal shift, as WinHelp was immediately adopted as the standard for documentation in Windows-native applications, supplanting older text-file approaches and becoming integral to core system utilities like Control Panel and Program Manager.[3] Third-party developers rapidly embraced it for their GUI software, recognizing its ability to provide context-sensitive help directly from menu items or dialog boxes, which enhanced usability in the burgeoning Windows ecosystem.[14]

Versions and Evolution

WinHelp 3.1, released in 1992 with Windows 3.1, provided enhanced support including improvements to indexing functionality that allowed for more efficient topic lookup and navigation within help files.[10] This version built upon the initial adoption of WinHelp in Windows 3.0, refining core features to align with the expanded capabilities of the 16-bit Windows environment.[3] A significant evolution occurred with WinHelp 4.0 in 1995, which was bundled with Windows 95 and Windows NT 3.51, marking the transition to a 32-bit architecture for broader compatibility and performance gains.[15] This release introduced the tri-pane interface—comprising contents, index, and search panes—for streamlined user access to information, along with support for hotspots that enabled interactive elements like buttons and links, and an expanded macro system with 26 new commands to automate dynamic behaviors in help content.[16] These enhancements reflected Microsoft's push toward more sophisticated, application-integrated documentation tools. In 1996, with the release of Windows NT 4.0, WinHelp 4.0 received minor updates offering improved 32-bit compatibility and optimizations particularly suited for enterprise environments, ensuring seamless operation.[10] Subsequent minor updates extended through Windows 2000 and XP, focusing on stability and integration without major architectural changes, as WinHelp remained the default help viewer in these releases.[17] The progression of WinHelp versions was primarily driven by the need to synchronize with underlying operating system advancements, such as the full embrace of 32-bit processing for enhanced efficiency and the early incorporation of hyperlink-like features that hinted at future internet connectivity in documentation systems.[4]

Technical Specifications

File Format Details

The WinHelp file format, a proprietary binary structure developed by Microsoft, is fundamentally based on the Rich Text Format (RTF) for storing textual content within compiled help files (.hlp). It begins with a 16-byte header, where the first four bytes serve as the magic number identifier: 0x3F 0x5F 0x03 0x00. This header includes an offset pointing to an internal directory file, which organizes the file's contents as a series of embedded "internal files" in a B+ tree structure, each preceded by a 9-byte header specifying its size. Key internal files include |SYSTEM for metadata, |TOPIC for content blocks, and |Phrases for index phrases, with the entire format supporting compressed data streams to optimize storage.[18] The core content is housed in topic blocks within the |TOPIC internal file, where each block consists of a 12-byte header followed by variable-length data, typically up to 2048 bytes in early versions (1.15) or 16384 bytes in later ones (1.21 and above). These blocks contain TOPICLINK structures that delineate individual topics, spanning multiple blocks if necessary, and include fields for record type, size (excluding headers in some versions), and pointers to subsequent links. Text within these blocks is stored as compressed RTF, employing an optional HLP-LZ77 compression algorithm in versions 1.21 and later, which uses a 4096-byte ring buffer for LZ77-style matching to reduce redundancy while preserving RTF control words for formatting like bold, italics, and hyperlinks. Hyperlinks are implemented via topic IDs referenced in RTF markup, enabling navigation between topics without external dependencies.[19][20] Additional structural elements include a font table embedded in the RTF stream to define available typefaces and sizes (e.g., DEFFONT 0 for the default, with sizes in half-points), ensuring consistent rendering across Windows environments. Non-scrolling regions, such as fixed headers or footers, are defined through RTF extensions and topic block attributes, allowing persistent UI elements during navigation. Embedded bitmaps for illustrations are supported directly in the topic blocks, often using run-length encoding for compression, integrated via RTF \pict controls. The format accommodates up to 16 MB per .hlp file and a maximum of 32,767 topics in later versions, limited by 16-bit indexing in the project mapping.[20][21] Regarding security, the WinHelp format lacks built-in encryption or authentication mechanisms, relying solely on file permissions for protection, which exposes it to tampering. It is vulnerable to exploitation through malformed RTF content or embedded objects, potentially enabling remote code execution without user interaction, akin to vulnerabilities in RTF parsers; no native macro sandboxing exists, allowing potentially malicious RTF macros to execute if processed by compatible viewers.[22]

Accompanying File Types

WinHelp help systems primarily rely on the .hlp file for core content delivery, but are frequently supplemented by optional accompanying files that enable advanced navigation, search, and user customization features. These files are loaded dynamically by the WinHelp viewer (winhlp32.exe) when the .hlp file is opened, enhancing user interaction without being mandatory for basic functionality. However, their presence is crucial for comprehensive features like structured browsing and keyword-based retrieval.[7] The .cnt file serves as the contents file, defining the table of contents for the help system in a binary format that organizes topics hierarchically. It lists topics and subtopics in a tree structure, facilitating easy navigation through the help content via the viewer's Contents tab. This file is typically generated during the compilation process and pairs directly with the .hlp file to display the outline view.[6] Full-text search capabilities are supported by the .fts and .ftg files, which function as index files for keyword queries across the entire help content. The .fts file contains the actual search index in a binary format, allowing users to perform searches for specific terms or phrases within topics, while the .ftg file acts as a grouping mechanism to link multiple .fts indexes together, particularly useful in larger or multi-file help projects. These files enable efficient querying without scanning the full .hlp content each time.[23][24] Additional runtime and customization files include the .gid, .ann, and .bmk files, which handle indexing, user notes, and saved positions. The .gid file is a global index and configuration file created automatically by the viewer upon first access to an .hlp file, storing details like window dimensions, positions, and search-related metadata to support context-sensitive help mappings and persistent settings. The .ann file stores user annotations as plain-text notes attached to specific topics, permitting personalized comments without altering the original help content. Similarly, the .bmk file manages bookmarks in a simple format, enabling users to mark and quickly return to favored sections. These files are user-specific, often located in the same directory as the .hlp, and are essential for tailored experiences in context-sensitive scenarios.[23][25][26]

Authoring Process

Source Materials

The creation of WinHelp content begins with a set of input files that provide the textual, graphical, and structural elements necessary for the help system. These source materials are primarily authored using standard word processors and graphics tools before being processed by the help compiler. The core components include text files in Rich Text Format (RTF), image files in supported bitmap and vector formats, and project files that define the overall structure and build parameters.[6][27] RTF files serve as the primary source for textual content in WinHelp authoring, containing the formatted topics, paragraphs, and hyperlinks that form the body of the help documentation. These files support rich formatting features such as fonts, colors, bold and italic text, and layout controls, achieved through RTF control words like \fonttbl for font tables, \colortbl for color definitions, and \par for paragraph breaks. Hyperlinks and navigational elements are embedded using specialized Help macros, such as footnotes with # for topic IDs, k for keywords, $ for titles, and + for browse sequences, enabling context-sensitive jumps and structured navigation within the compiled help file. Authors typically create multiple RTF files, each focusing on a specific set of topics (e.g., one for command references and another for tutorials), to maintain organization and facilitate updates.[27] Image files are integral for illustrating concepts and adding interactive elements, integrated directly into RTF topics or referenced in the project file. Supported formats include Windows Bitmap (.bmp) for raster images, which can be embedded inline using the bmc macro or wrapped for alignment with bml and bmr; Windows Metafile (.wmf) for scalable vector graphics, suitable for diagrams that require resizing without quality loss; and Segmented Hotspot Graphics (.shg) for interactive images with clickable regions, where hotspots are defined to link to specific help topics. These images must be listed in the project file's bitmap section or organized under a root directory for efficient referencing, with monochrome or 16-color BMPs recommended for compatibility with early Windows display modes like CGA and EGA.[27] The Help Project file (.hpj) acts as the central configuration document, specifying which RTF and image files to include and how to assemble them. It consists of sections such as [FILES] to list all RTF topic files, [BITMAPS] to enumerate image paths (with options like BMROOT for relative directories), [OPTIONS] for build settings like compression and default windows, and [MAP] for mapping context strings to topic IDs, ensuring seamless integration for application-specific help calls. Additional sections like [CONFIG] define display behaviors, such as secondary windows for glossaries, while [ALIAS] allows shorthand for complex context identifiers. The .hpj file is typically edited in a plain text editor and serves as the blueprint for the compilation process.[6][27] Best practices for authoring these source materials emphasize modularity and compatibility to ensure maintainable and effective help systems. RTF topics should be kept concise and self-contained, with each file limited to related subjects to avoid monolithic documents that complicate revisions; for instance, separating procedural guides from reference materials promotes reusability. Authors are advised to use unique, alphanumeric context strings (up to 128 characters for titles and 255 for keywords) without spaces or special characters to prevent mapping errors, and to place all footnotes in the first paragraph of each topic for proper indexing. Complex nesting of tables or hidden text should be avoided, as it can lead to compilation issues, while graphics should be optimized for size—employing monochrome BMPs where possible—to minimize the final file footprint. Testing across different resolutions and validating macro syntax early in the process helps catch incompatibilities before compilation into the .hlp format.[27]

Compilation Tools and Steps

The primary tool for compiling WinHelp files is the Microsoft Help Compiler Workshop (HCW.exe), an official utility released by Microsoft in the 1990s to transform source materials into the proprietary .hlp format. This graphical interface allows developers to manage projects and invoke the underlying help compiler executables, such as HCRTF.exe for processing Rich Text Format (RTF) content. HCW.exe was designed for Windows environments starting from Windows 3.1 and remains the standard for building legacy WinHelp systems, though it requires manual setup on modern operating systems due to deprecation.[28] The compilation process begins with creating a project file with the .hpj extension using HCW.exe, which serves as the central configuration listing all input files, options, and output specifications. Authors add RTF topic files—containing the help content with embedded hotspots and formatting—directly into the project via the "File > Add" menu, along with optional .cnt files for table of contents structure and .fts files for full-text search indexing. Once the project is saved, compilation is initiated by selecting "Save and Compile" in HCW.exe, which processes the RTF files, resolves cross-references, embeds bitmaps, and generates the primary .hlp output file, along with .cnt and .fts if specified. The resulting files are binary and optimized for the WinHelp viewer.[29][30][31] After compilation, testing is essential and typically involves launching the compiled .hlp file using the WinHelp viewer, winhlp32.exe, accessible via the "File > Run WinHelp" option in HCW.exe or by double-clicking the file in Windows Explorer. This step verifies navigation, search functionality, and context-sensitive links without requiring integration into an application. Errors during compilation, such as unresolved references or memory issues with large projects, are reported in a log window, which can be enabled for debugging.[29][30] Third-party tools like Adobe RoboHelp and HelpScribble extend the authoring and compilation workflow by providing integrated environments that automate .hpj creation, RTF editing, and HCW.exe invocation, reducing manual steps for complex projects. These tools support advanced features such as version control integration and multi-format output, while still relying on Microsoft's compiler for the final .hlp generation. For instance, HelpScribble generates project structures and compiles directly to WinHelp, streamlining production for standalone or application-embedded help systems.[32][33] A key limitation of HCW.exe is its single-threaded operation, which can lead to performance bottlenecks when processing extensive RTF sources or numerous graphics, as the tool originates from pre-multicore era software development. Additionally, the output is inherently locked to the WinHelp format, preventing direct generation of modern alternatives like HTML Help without additional conversion steps. These constraints make it unsuitable for large-scale or contemporary documentation pipelines.[30]

User Interface and Features

Visual Appearance

The WinHelp viewer displays content in a resizable secondary window that functions independently of the calling application, featuring a standard title bar, system menu, minimize and maximize buttons, a menu bar with File, Edit, and Bookmark options for basic operations like printing and navigation history management, and an optional toolbar containing buttons for common actions such as back, forward, contents, index, and search.[7] Introduced in version 4.0 and later, the Help Topics dialog box provides navigation options with tabs for Contents (hierarchical topic outline), Index (alphabetical keyword listing), and Search/Find (full-text querying); selecting a topic from the dialog displays it in the primary window's main topic pane, which renders the selected help content; secondary windows, lacking a menu bar but supporting customizable toolbars, can be opened for focused topics or popups that appear near specific UI elements.[7][34] Help topics are rendered using Rich Text Format (RTF), enabling rich styling such as customizable fonts, colors, bold, and italics to emphasize key information, with embedded bitmap or metafile images integrated directly into the text flow and automatically scaled to fit within the available pane width for optimal display.[35][36] Developers customize the visual layout through the .hpj project file, particularly the [WINDOWS] section, where parameters define window names, initial sizes (e.g., width and height in pixels), positions (e.g., screen coordinates), and toolbar visibility for primary and secondary windows; prior to Windows XP, WinHelp lacked support for visual themes, relying on the native Windows 95/NT-era appearance without modern styling options.[34][1] WinHelp offers multiple navigation options to facilitate user access to help content within its viewer window. The Contents tab presents a hierarchical tree structure of topics, defined by the optional .cnt file, which outlines topic IDs, titles, and indentation levels to create expandable folders and subtopics for organized browsing. The Index tab provides an alphabetical keyword list, allowing users to select or search for entries that link directly to associated topics. Complementing these, the Find tab enables full-text searches across the entire help file, utilizing an index file (.fts) that is built the first time the Find tab is used and indexing is enabled, with the precision of matches depending on the completeness and quality of this runtime indexing process. Hyperlinks and hotspots enhance intra-document navigation by embedding interactive elements directly in the content. Hyperlinks, typically rendered as solid underlined green text, connect to other topics via context labels, enabling seamless jumps without leaving the main window. Hotspots extend this interactivity to non-text areas, such as clickable regions in bitmaps or dotted underlined phrases in text, which can trigger immediate jumps to related sections or display contextual information. Core functionality includes context-sensitive help, invoked by applications through the WinHelp API using specific topic IDs to display targeted assistance for UI elements like menus or dialogs. Pop-up windows deliver concise, non-modal explanations, such as glossary definitions, activated by hotspots and overlaying the main content temporarily. For customization, macros allow authors to define scripted actions—like button behaviors or startup routines—while DLL extensions enable deeper integration, such as implementing custom macro handlers or processing WinHelp messages for advanced interactions. Advanced user features support personalization and multimedia, albeit with constraints. Bookmarks let users mark favorite topics for quick recall, stored in .bmk files, and annotations permit adding personal notes to topics, saved in .ann files for later reference. Jump buttons, customizable by authors and often appearing as << and >> icons, facilitate sequential navigation through predefined topic chains. Later WinHelp versions introduced limited audio and video embedding, primarily via macros that launch external tools like Media Player for playback, rather than native rendering. However, the system lacks support for dynamic scripting like JavaScript, limiting interactive elements to static hyperlinks and basic macros, and search reliability hinges on the .fts file's construction without advanced stemming or fuzzy matching.

Deprecation and End of Support

Announcement and Timeline

Microsoft announced its intention to deprecate WinHelp in March 2006 during discussions with Most Valuable Professionals (MVPs) and at the WritersUA conference, stating that the format did not meet modern code standards and would be phased out.[37][10] The full phase-out was declared the same year, with WinHelp no longer shipping as a core component in subsequent Windows versions.[2] The deprecation timeline began with the release of Windows Vista in January 2007, where WinHelp was removed by default from the operating system installation.[5] To support legacy applications, Microsoft provided a downloadable viewer (WinHlp32.exe) for Vista and later versions up to Windows 8.1, released in October 2013.[2] This viewer enabled users to open .hlp files but required manual installation. The downloadable option remained available through Windows 8.1 in 2014.[2] On July 15, 2015, coinciding with the release to manufacturing (RTM) of Windows 10, Microsoft completely removed WinHelp support, including the option for downloading the viewer. No further official support or downloads were provided for Windows 10 or later versions.[5] As part of the deprecation policy, Microsoft encouraged developers to migrate from WinHelp to alternative formats such as Compiled HTML Help (CHM) to align with enhanced security and web-based documentation standards.[5] This transition was emphasized to address the format's outdated nature and vulnerabilities.[2] The immediate effects included breakage in legacy applications relying on .hlp files, resulting in error messages such as "Feature not included" or "Help not supported" when attempting to access help content without the viewer on affected systems.[5] Users of older software on Windows Vista and beyond often needed to install the provided patch to restore functionality temporarily.[2]

Reasons for Phase-Out

One key factor in the deprecation of WinHelp was its inherent security vulnerabilities, stemming from the format's support for macros embedded in RTF content, which could execute arbitrary code directly within the viewer. The WinHlp32.exe viewer operated without sandboxing or isolation mechanisms, allowing malicious .hlp files to run with full user privileges and potentially compromise the system. This lack of containment made WinHelp a prime attack vector, with real-world exploits including help-file-based viruses and buffer overflows that enabled remote code execution.[4][4] Technically, WinHelp's foundation on Rich Text Format (RTF) became obsolete as it struggled to match the flexibility of HTML and CSS in newer documentation systems, restricting advanced styling, multimedia integration, and dynamic content. RTF's uncompressed structure also hindered performance for expansive help systems, leading to slower loading and navigation compared to compressed, hyperlinked HTML formats. These limitations made it increasingly incompatible with evolving software development needs, such as scalable, web-compatible documentation.[38][38] Strategically, Microsoft pursued a transition to web-oriented help solutions, announcing in 1996 the cessation of WinHelp development in favor of HTML Help to better support internet-integrated experiences and align with emerging frameworks like .NET. This shift emphasized online resources such as MSDN web portals, reducing reliance on standalone, proprietary viewers and promoting broader accessibility across platforms. By making WinHelp optional rather than core to Windows, Microsoft aimed to streamline the OS footprint while encouraging adoption of modern, extensible formats.[10][10][4] Developer input further underscored these issues, with feedback from Microsoft Valuable Professionals (MVPs) highlighting the maintenance burdens of WinHelp's aging toolchain and the appeal of cross-platform alternatives that simplified updates and distribution. The format's proprietary nature complicated long-term support, prompting calls for migration to more versatile systems amid rising complexity in help authoring workflows.[37][39]

Legacy and Alternatives

Modern Compatibility Issues

Windows 10 and later versions, including Windows 11, do not include native support for the WinHelp viewer (WinHlp32.exe), resulting in errors when attempting to open .hlp files from legacy applications.[5] Users must download the WinHlp32.exe executable from Microsoft or extract it from older operating systems like Windows 7, though these methods are unofficial and may require manual installation or renaming to bypass system restrictions.[5] To address these limitations, community-developed workarounds include GitHub projects such as hlp4win11, which automates the download, extraction, and installation of the official Microsoft WinHlp32.exe for Windows 10 and 11.[40] Additionally, tools like Help to RTF enable conversion of .hlp files to RTF format, allowing access without the legacy viewer.[41] In enterprise environments, the absence of WinHelp support impacts legacy software that relies on .hlp files for documentation, potentially disrupting workflows in sectors maintaining older systems.[42] Microsoft Knowledge Base articles offer partial solutions through downloadable executables tailored for 32-bit and 64-bit editions, but these do not restore full integration.[5] As of 2025, Microsoft provides no official support for WinHelp, with compatibility confined to community-maintained viewers and conversion utilities for archival or limited access purposes.[5]

Successor Documentation Formats

HTML Help (CHM), introduced in 1997, served as the primary successor to WinHelp, compiling multiple HTML files, images, and other resources into a single compressed .chm file for efficient distribution and viewing.[43] This format supported advanced features such as table of contents, indexes, frames, scripting with JScript or VBScript, and integration with ActiveX controls, making it suitable for software application help systems on Windows platforms.[43] It became the primary successor to WinHelp and the default help format for many Windows applications. Although native support continues in modern Windows versions, Microsoft has identified security vulnerabilities in CHM files and encourages the use of web-based documentation systems.[43] Microsoft Help 2.x, released in 2001, provided an XML-based alternative primarily for developer documentation, such as in Visual Studio and MSDN libraries, offering improved search capabilities and integration with .NET frameworks through compiled .hxs files.[44] This format emphasized structured content and extensibility for technical audiences but was not adopted as a general replacement for CHM; it was deprecated in the 2010s with the introduction of the Microsoft Help Viewer for Visual Studio 2010 and later versions.[10] In the modern era, Microsoft recommends web-based help systems using HTML5, CSS, and JavaScript for responsive, cross-platform documentation that leverages online accessibility and search engine integration, as seen in platforms like Microsoft Learn.[45] Alternatives include PDF for static, printable content and tools like DocBook, an XML-based standard that enables multi-format outputs such as CHM, EPUB, and web pages, facilitating easier maintenance and broader device compatibility. Migration from WinHelp to these successors is supported by tools like Adobe RoboHelp, which can import .hlp and .hpj files to generate CHM outputs while preserving navigation structures, offering benefits like enhanced security against exploits and improved responsiveness on contemporary systems.[46] These transitions address WinHelp's limitations in handling modern web technologies and multimedia, promoting more dynamic and secure user experiences.[47]

References

User Avatar
No comments yet.