Hi Eric, > Is it possible to build the table when apps start
The search table is a crucial part of the format, as it stores the offsets of the individual strings. So you cannot simply leave this out. But if you establish the hard requirements that every string does not contain but ends with a binary zero or some other marker, and the string ids are consecutive and start at a certain number, one could generate the search table on the fly without needing the translation source files. > and make the format editable without needing a special toolchain? Well, handling binary data almost always requires some "toolchain" :) Editing of the UTF-8 source files can of course be done using an ordinary text editor. But to "compile" the binary file from the sources, a tool is needed. A GUI tool that can do both editing and .LNG generation would be nice to have. I am currently not 100% satisfied with the format of the source files. Luckily the binary .LNG format is independent of the source format. So if in the future I implement another source format and "compiler", the binary file should stay the same. > It could also use some sort of compression people have around anyway, such as > GZ or ZIP :-) Sure it could use GZ. But that would blow up the code size by a factor of ten or more, I guess. The primary design idea of SvarLANG is to keep things minimal. The current decompressor is implemented in around 20 lines of C code. The compressed .LNG file for FDISK is 41k, while the uncompressed is 110k. So we consider this "efficient enough" that inclusion of a more advanced compression algorithm is not justified. Bernd _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel