Bart Oldeman escribió:

On Sun, 25 Apr 2004, Aitor Santamaría Merino wrote:



Bernd Blaauw escribió:



right now on updated ODIN bootdisk the CPI files take almost 600KB (10
* 60KB),
which is nearly half the disk! (and makes creating 720KB more difficult).


Perhaps it's a question to check the CPI files, perhaps for MOST of the
countries, just 2 or 3 of those CPI files are not enough, and not 10 of
them.
It's just a question of where to put the limit.



What was the compression proposal about? Help files or CPI files?


Actually current HELP works with compressed files inside a ZIP. DISPLAY just needs an in-memory image of a whole CPI file, so it's ok if MODE does a similar uncompression job.
Something similar happens for DR-FONTS (as explained by Matthias): there's no TRUE compression, but MODE manages to compose a correct CPI file from data organized other way inside the CPI file.


For the CPI files it would really help since they compress 90%, and if you
concatenate them together and then zip them it only takes up 34K instead
of 600K. So a single compressed EGA.CPI would be really nice.


There's a list of country-specific settings (affecting KEYB, DISPLAY/MODE, SET LANG=, COUNTRY=) created by Henrique, used by Bernd to tune up install that could give a clue of which are the most frequently used CPI files.
Pitty that due to segment boundary limits, CPI files can have info for no more than 6 codepages (about 9.5KB for each).
Second pitty is that there are certain codepages that are repeated once and once again (e.g. 437 and 850 may appear in many of them). My understanding is that for every country you can do it all with a SINGLE CPI file (Henrique knows better, I don't release CPI files).
Third pitty is that if you configure DISPLAY to a minimum, you at least require two memory resident buffers, one for one prepared codepage, other for the selected codepage (and for MS compatibility, they are different buffers), of about 9.5KB each. And whereas the selected must reside in convenctional memory, the prepared one (ALL the prepared ones) could be living on XMS and be copied low when required. However, I don't plan to implement this (assuming there are no problems with calling HIMEM in the middle of a IOCTL call, probably not).


Aitor


------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to