>> 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.
Many times more. There is no *one* ZIP or GZ compression alghorithm; there are
multiple different ones.
Each of them is probably more then ten times larger (with both LZW and
arithmetic encoding). And none of them builds binary trees ...
> 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.
+1
My suggestion would be to attach these language data to the end of the .exe
file, so there is
only one resource (the .exe file) to be managed. And updating the .exe also
updates the language resource.
>Finally, CATS requires default strings
>to be part of the application's source code, while SvarLANG keeps all strings
>in TXT files and embedds the default one inside the application in an automated
>way at compile time.
A horrible idea. When navigating (discovering) software written by other people
it's
extremely helpful to have message strings sprinkled through the sources.
...
result = dosomething();
if (result != 0)
printf("%s\n", kittengets(1,22, "can't write file. Disk full??"));
is much easier to navigate then
if (result != 0)
printf("%s\n", kittengets(1,22));
In particular if you try to locate the issue that prints "Disk full".
It's also a matter of taste. YMMV.
Tom
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
