Hola Eduardo,
I don't mind adding the changes to nls_hc.asm, but I'm not sure that I like that option.
Neither do I like it very much, but (1) and (3) are most straightforward and easiest to implement.
In a private mail, Eric suggested a fourth option: Check if there is enough room for loading the package and, if not, allocate extra memory only for the additional tables.
This will keep the kernel size unchanged and optimze the memory useage, as only a percentage of NLS packages are bigger than the default.
The problem is that the already statically allocated memory for hard-coded tables will be lost.
I've been thinking about how to implement this, and I've come up with this:
We could insert a null pointer for subfunction 0 just before subfunction 1 (CTYINFO) into nls_hc.asm, which will be ignored by NLS functions as subfunction 0 does not exist (example patch below). This will add just 5 bytes to the tables and can be used as a placeholder for subfunction 3 (LCASE). This maintains all the pointers into predictable indexes and prevents moving the CTYINFO table when loading a package with LCASE.
When loading a package from COUNTRY.SYS, we should do something like the following pseudocode before actually reading the data:
extra_memory = 0;
if (LCASE_is_present) extra_memory += 258; /* sizeof(WORD) + actual length */
if (UCASE_offset != FUCASE_offset) extra_memory += 130;
if (DBCS_length != 0) extra_memory += 2 + DBCS_length; /* sizeof(WORD) + actual_length */
allocate(extra_memory);
And then, read the info overwriting the harcoded tables for UCASE, FCHAR, CTYINFO, YESNO and COLLATE and into the allocated memory for LCASE, FUCASE (if different than UCASE) and DBCS (if non-empty.)
But we will have a common memory for all the information and could not distinguish between the beginnings of the different structures. It's better to allocate memory separately for each one.
I still think that half a kilobyte isn't a big price to pay, PROVIDED THAT SOMEONE WILL REALLY USE THE DOUBLE-BYTE TABLES. As far as I know, there are complete Chinese, Korean and Japanese packages that install their own font, NLS and keyboard support, and most people will use them and not our inferior but much more difficult to set up COUNTRY + NLSFUNC + DISPLAY + KEYBOARD + whatever :-/
If nobody will use them, then your option (1) is the one to implement.
Chinese, Japanese and Korean friends, please express your opinion now.
Last not least, we don't have these tables yet, and may not have them.
Regards, Lucho
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
