reverse engineered chm spec and the complexity boggles my mind: https://www.nongnu.org/chmspec/latest/
reverse engineered chm spec and the complexity boggles my mind: https://www.nongnu.org/chmspec/latest/
These days I think I would have used Kaitai Struct to create a declarative specification and generated library code and a human-readable specification from that.
The reverse engineering of the CHM format was pretty rewarding though, it felt good to bring CHM access to the Linux community. I never got as far as scratching my original itch of having a CHM compiler that runs on Linux, instead I got distracted by open source and just ditched the proprietary world entirely.
If anyone feels the need to get involved in open source but isn't sure how or where, reverse engineering proprietary formats, drivers and firmware is needed now more than ever and is very rewarding both intellectually and for enabling the community.
I wish Microsoft had used an existing standard container format like ZIP instead of inventing yet another container format. They have created lots of different container formats over the years; OLE, ITSF, istorage from back then and probably more in recent times.
Everybody knows how to author html, if xml is some specific new set of rules, what is the advantage of that approach?
If it is xml, what makes it different from the epub format? Is epub format the subset? What were the advantages of it not being the subset?
As for XML - it's ch easier to make a stable parser that is complete and fast for XML than it is for SGML-based HTML, and indeed the was a big push towards XML everywhere... Partially because of that reason.
And it was not designed for context-sensitive help of desktop apps, while LiteHelp is.