Hi, the last week I worked on HTMLHELP fixing various bugs, and initial tests by Fritz Müller and me give hope that the crashes and display corruptions are gone. The changes made so far, which will make it into the next FreeDOS interim build, are:
! Fix a heap corruption bug leading to crashes and display artifacts ! Fix stack overflow in full text search leading to program crash ! Fix a crash caused by a stack corruption bug in fnsplit function ! Fix a crash caused by a stack corruption bug in search GUI function ! Fix integer overflow bug in vertical scroll bar display code ! Fix UTF to CP 857 conversion table entry for unicode codepoint 0x11F ! Fix UTF to CP 852 conversion table entry for unicode codepoint 0x179 * Display currently searched file while performing full text search * Add several HTML entities to substitution table * Add support for codepages 775, 848, 849, 1125, 1131 ~ Speed up unicode to codepage translation ~ Speed up HTML entity substitution ~ Changed default calling convention from C to Watcom There are still many parts of the software which can be improved. The most urgent one is the barely usable full-text search, which it is really slow. It is slow because HTMLHELP stores its files in a compressed ZIP archive, and doing a full-text search inside a compressed archive on an old machine is not lightening fast, especially if you reopen the ZIP file a few hundred times while doing the search. I would like to throw out all the ZIP functionallity (20Kb), and bring the size of the code segment down to under 64K, enabling using the compact memory model. But for ease of use HTMLHELP should continue letting the help author ship the help files within some form of container format. Call me crazy, but the most simple solution would be using the .PAK container format used by the Quake 3D engine. An implementation can be done in around 100 LOC. See https://quakewiki.org/wiki/.pak If no one intervenes I would like to do a proof of concept implementation to see how it performs. A second area that needs improvement is the unicode to codepage translation. While this works reasonably well now, the increasing number of conversion tables linked into the binary is becoming a real memory waster. Obvious solution would be to throw them out of the binary, and only load the needed translation table from an external file. Which leads to the next question: Should these tables be stored in a central, well defined directory within FreeDOS, accessible to all programs doing this translation stuff? There is little to no need for every program to reinvent this wheel. Perhaps such a general solution already exists? Happy to get feedback, Bernd _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
