caseih wrote: There were really only two choices. Either compile it into a binary tree once and store the result to a file for fast loading (probably memory-mapped and usable directly), or compile it every time the help file is open.
Yes. Not memory mapped since the tables are stored compressed afaik (with a lz77 derived algorithm also used by .CAB though headers vary). But indeed directly searching without further operations after decompressing was one of the reasons. Speed of on the fly combining the results of multiple CHMs was probably one of the reasons too.
Even that can be cached in a CHW file even (mostly for IDEs with large SDKs installed), but since VS moved on, that is not used much anymore.
Given the hardware constraints of the time, I can understand why they chose the former. Now of course we would choose the latter every time, as that divorces the in-memory format from the disk format, which is desirable for portability and standardization reasons, as well as flexibility. Just like how we now use XML-based formats for MS Office.
The whole reason for XML was a threat to the acceptance of closed formats (old .doc) by governments. It was not a technical decision, or anything that even related to any daily reality of ordinary office users.