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

Reply via email to