> I _am_ interested, it is only that I can not make any commitment. The > NLSFUNC stuff sounds good. Can you send me the info you have? No > promises, you know, but... Thanks ;-). NLSFUNC implements an handler for the function which does the core of the CHCP work. So when you do CHCP somecodepage, then NLSFUNC is activated. NLSFUNC gets the somecodepage value from the caller. It asks the kernel for the country,sys location (as passed in the COUNTRY= line: FreeDOS ignores this value in current kernels, it only checks the country itself: COUNTRY=049,437,x:\country... would be interpreted as COUNTRY=049). You can also pass the location as a command line argument when you load NLSFUNC as resident program, so it does not really hurt that kernel support is not all complete. I am not sure, but NLSFUNC might also check the current codepage from DISPLAY or the kernel. Anyway. It will use int 2f.12 (because this happens inside int 21, you cannot use int 21!) to read the country,sys file. It will parse it (no idea about the file format, but we could create some ad hoc format for a FreeDOS variant country.fd...). It picks the country settings (date/time format etc.) for the selected country / codepage and sends them back to the kernel (the FreeDOS kernel API for this is more or less complete, but you can just overwrite the data structures in kernel RAM otherwise ;-)). Now NLSFUNC browses the device driver chain (entry point can be found through the list of lists, check the MEM source code) and tries to tell every driver which supports IOCTLs about the change. In particular, it will tell DISPLAY, which in turn will tell KEYB through another API (I did not invent this weird system...) ... Drivers which do not support THAT IOCTL are more or less ignored. If the codepage change interface is supported, NLSFUNC somehow collects information if the codepage change failed anywhere. If the codepage is not available in country.* file at all, the whole change fails, too, of course. So NLSFUNC has the purpose to parse the country.* file and to propagate the settings for the new codepage to the kernel and all drivers on a CHCP event. I have some more technical documentation about that somewhere in my mailbox... What I do not have is probably information about the country.* file format, but as told, you can use an ad hoc format for now. The involved interfaces are documented in RBIL, DISPLAY source code (notice that DISPLAY is no real device driver yet, but can be reached through int 2f which seems to be the standard way anyway) and kernel source code. There is also a longish technote (technote 141, changing codepages in FreeDOS) about the issue. CHCP calls int 21.6602 and int 21.6601 ... Your mission, should you chose to accept it, is to implement NLSFUNC as a TSR which provides int 2f.140x functions. KEYB is already informed by DISPLAY, so you would have to tell only DISPLAY, not KEYB. You can find information about how to do this in the MODE source code: MODE changes the DISPLAY (and indirectly KEYB) code- page, but does not (different from NLSFUNC) change the kernel and other-driver (like PRINTER) codepage. In the KERNEL source code you can read how the COUNTRY line changes the kernel codepage (I think it ignores the (e.g. 437) "hardware codepage" (graphics card font codepage) value, though). To change kernel codepage information, use int 21.650x which gives you pointers to the country information tables (so you can simply overwrite them in RAM). NLSFUNC provides services for int 21.650x for other codepages than the default, but I think if you want other than the current codepage to be accessible then NLSFUNC has to take more RAM (to load the requested info into RAM without having to change kernel codepage to that codepage) - maybe there could be an NLSFUNC command line option about how many codepage / country data buffers should be allocated? On the other hand, very few programs need information about any other codepage than the current one at all. Being able to use CHCP is the most useful NLSFUNC service. Without NLSFUNC, you can only use the COUNTRY= line and MODE CON CP functions (for DISPLAY / KEYB), and changing COUNTRY= cannot be done "on the fly". To increase confusion, there is also int 21.38 which copies country settings (data structure) to a buffer provided by the user or sets the country code... THe API of NLSFUNC itself is in int 2f.140x (install check, pass updated int 21.65 information from kernel to NLSFUNC, receive int 21.65 information from NLSFUNC (called by kernel when int 21.65 is called, so NLSFUNC itself does not have to provide int 21.65 services!?), set code page, get country info (called by kernel when int 21.38 is called, so NLSFUNC itself does not have to provide int 21.38 either...), ...). Luckily RBIL seems to EXPLAIN COUNTRY,SYS FILE FORMAT along with int 2f.140x description! NLSFUNC uses int 2f.1226/1227 to open/close that file without having to use int 21 functions. It also uses int 2f.1228 (seek) and int 2f.1229 (read) for the same thing. There even is int 2f.122b for IOCTLs but I think you could just as well call the device drivers directly for those IOCTLs from NLSFUNC... To get the first (actually second) device driver pointer, you can use either the list of lists or int 2f.122c ... NLSFUNC gets the country file name from the kernel through int 2f.140x, too. The "life cycle" of a CHCP as processed by NLSFUNC is explained in technote 141 in the section "When you issue INT 21h/6601h"... CHCP -> 21.660x -> if needed -> 2f.140x (here NLSFUNC comes into play) -> NLSFUNC uses int 2f.122x to read the country file -> information is returned to the kernel -> NLSFUNC uses direct access or int 2f.122x to IOCTL the news to all device drivers, one after another (basically only DISPLAY and PRINTER, and PRINTER is checked for being busy through int 2f.0106) -> DISPLAY tells the news to KEYB, and DISPLAY/PRINTER switches will only work if you have used MODE to prepare them for the codepage in question before, because information for those is in .CPI files, not in the COUNTRY file... the KEYB update is done through int 2f.ad8x by DISPLAY... long story about DISPLAY but already ready and implemented anyway :-)... Further, kernel will use int 2f.140x to let NLSFUNC provide data whenever int 21.38 / int 21.65xx is called. So: Your MISSION, should you chose to accept it, is to implement int 2f.140x ... Country data and int 21.38 / 21.650x data will flow to / from the kernel through this int 2f.140x interface. File accesses to the COUNTRY file have to be done through int 2f.122x by NLSFUNC. NLSFUNC is accessed through int 2f.140x and must not use int 21 functions except 00..0c for what it does for int 2f.140x (but you can of course use all int 21 functions during initialization, only the int 2f handler of NLSFUNC must not use int 21...). NLSFUNC will also have to (try to) send IOCTLs to all devices, either directly or with help of int 2f.122x ... For the current DISPLAY version, you would use int 2f.ad0x instead of using IOCTLs. Actually, the int 2f.ad0x interfacs is an MS DISPLAY compatible one. I believe nobody will complain if you first have an NLSFUNC which does NOT use IOCTLs and does NOT try to inform all drivers at all - just having the int 2f.140x functions, parsing the COUNTRY file and calling int 2f.ad0x to tell DISPLAY about the change should be enough. For parsing the COUNTRY file, use int 2f.122x for file access. The FILE FORMAT is explained in RBIL along with the description of int 2f.1401, see tables 02618 ... 02622 and optionally 02623 ... 02624. You may want to start with a dummy NLSFUNC which just shows debug messages when one of the int 2f.140x functions is accessed. The next stage would be a COUNTRY file parser, third would be COUNTRY file access and parsing from withing int 2f.140x through int 2f.122x, displaying the parsed data. First really useful version would return the parsed data through the int 2f.140x interface. Next version would also inform DISPLAY through the int 2f.ad0x interface and a final version would also surf the device chain to broadcast the change through IOCTLs. Wow. That is kind of a long mail. But it also helps me to understand more about NLSFUNC internals myself. Hopefully it helped YOU to get started with NLSFUNC design and did not sound so weird that you run away screaming from your "maybe I could indeed help with NLSFUNC" plans X-). According to kernel documentation, int 21.38, 21.6501, 21.6505, 21.6506 work and if no NLSFUNC is loaded int 2f.1400, 2f.1402 and 2f.1404 are handled by dummy functions. Int 21.6601 works, too. Because int 21.6500 (change int 21.65xx information, Win95+) and int 21.6602 (set global code page table, opposite of int 21.6601 "get...") [there: table 01758, format of DOS .CPI ... file - only interesting for MODE / DISPLAY..., not for NLSFUNC] are not really there yet, it MIGHT be necessary to test NLSFUNC with a non- FreeDOS kernel (int 21.6602 is the function which is supposed to call NLSFUNC by calling int 2f.140x, but I did not check kernel sources for details) first. The "set" mode of int 21.38 would call int 21.6602, too. I can tell you that at least the first argument of COUNTRY=... does work in FreeDOS (sets the int 21.38 info, some voodoo without using a COUNTRY file) in some way. Unless you want to develop with a non-FreeDOS kernel first, you should probably look at the current kernel sources and / or ask on the kernel list to get extra opinions. For FreeDOS kernel, there are GRAB_UNF and UNF2HC and NLSUPTST tools to work with the hardcoded country information sets. In FreeDOS kernel, _syscall_MUX14 (see nls.h!) implements some basic codepage / country functionality. If NLSFUNC is loaded earlier in the int 2f chain (!), it can override that by more advanced functionality. It is possible that FreeDOS uses simplified / nonstandard data structures for int 2f.140x functions, so yet another reason to ask on the kernel list. You have some definitions about what API should be implemented by NLSFUNC in nls.h, they are the same as the RBIL listed ones. But data structures might be different. See in particular CountrySpecificInfo / nlsExtCntryInfo / nlsPointer / nlsPackage / nlsDBCS (but we need no DBCS now) / nslCharTbl / nlsFnamTerm / nslInfoBlock. I did not check but they do not look different to the MS compatible structures for me. COUNTRY file parsing might be a different story, see also csys_ccDefinition / nlsCSys_fileHeader / nlsCSys_loadPackage / ... As far as I can tell, muxLoadPkg, called by nlsSetPackage, already does call int 2f.140x as needed, but nlsCPchange is empty (no real problem, this only means that a codepage change will only be propagated to other device drivers if NLSFUNC helps by providing better int 2f.140x implementations than the kernel-builtin ones, I think). The kernel-builtin int 2f.140x handlers do support several codepages which are compiled into the kernel in in UNF->HC format but they do not support COUNTRY,SYS files. The COUNTRY,SYS thing has to be provided by NLSFUNC. This is from nls*.{c,h} from the kernel sources and from nls.txt from kernel documentation. > zipinfo NEW0303/srcdos/ke2035src.zip | grep -i nls | sed -e 's/.*fat//g' 8489 t- defX 6-Aug-00 05:42 SOURCE/KE2035/DOCS/NLS.TXT 29807 t- defX 7-Mar-04 11:50 SOURCE/KE2035/HDR/NLS.H 4143 t- defX 19-Mar-01 04:50 SOURCE/KE2035/KERNEL/NLS/001-437.HC 5356 t- defX 6-Aug-00 05:14 SOURCE/KE2035/KERNEL/NLS/001-437.UNF 256 b- defX 25-Apr-01 01:56 SOURCE/KE2035/KERNEL/NLS/001-437.UP 4144 t- defX 19-Mar-01 04:50 SOURCE/KE2035/KERNEL/NLS/049-850.HC 5358 t- defX 6-Aug-00 05:14 SOURCE/KE2035/KERNEL/NLS/049-850.UNF 256 b- defX 25-Apr-01 01:56 SOURCE/KE2035/KERNEL/NLS/049-850.UP 636 t- defX 6-Aug-00 05:14 SOURCE/KE2035/KERNEL/NLS/FILES 22296 t- defX 19-Mar-04 22:33 SOURCE/KE2035/KERNEL/NLS.C 4144 t- defX 9-Dec-02 00:17 SOURCE/KE2035/KERNEL/NLS_HC.ASM 2781 t- defX 27-Jun-03 23:02 SOURCE/KE2035/KERNEL/NLS_LOAD.C 2236 t- defX 30-May-04 20:31 SOURCE/KE2035/KERNEL/NLSSUPT.ASM