Hi Eric, > On Jul 28, 2021, at 8:15 AM, Eric Auer <e.a...@jpberlin.de> wrote: > > > Hi Jerome, > >> Just a thought on using “undocumented” function calls. > > COUNTRY=... and COUNTRY.SYS are not undocumented,
Only referring to the INT call as “undocumented”. :-) > but your > choice of words hints at another idea: Do you suggest to > introduce a TSR to handle string and key translations, to > be used by FreeDOS apps? I think this would not save enough > overhead compared to implementing translations in each app > to be worth the incompatibility. Remember that our kitten > implementation of catgets is very lightweight :-) I personally don’t use kitten/catgets for my NLS. There is nothing wrong with them. I just prefer mine instead. It’s not limited to the 0.0: type definitions. It could do that. But, I like using things like ERROR.NO-SUCH-DIR= in my stuff. In programs like those in V8Power Tools, it is done in assembly and reasonably fast. On to your question… Doing as a TSR brings to mind a couple complications. Nothing that is impossible to overcome, just adds some complexity. Just an high level overview leaving out many details… The lookup part of the service can be done in very few bytes of asm. As for the rest of it, maybe a K or so to do it right. For example, you’d probably want to hook the exec call to automatically monitor what program is launched. Then when the program asks for it’s first string, load the appropriate translation and return the string or error. You’d also want store the file in memory (XMS if possible) and free it when the program terminated. Also, for out of date translations, you would want to be able to fall back on the default translation. You would also use the callers segment to determine which program asked for the translation. Unfortunately, you must always have the TSR running or you don’t get any translations. It may be better to just have a loadable plug-in style driver. But, that requires much more overhead in the program. Better still to probably just keep compiling the programs with the NLS support library built into it. On the other hand, if support was built into the kernel or freecom, you get all the benefits of the TSR without most of the headaches. Plus, the shell could use it as well. However doing that, it would probably need to be the kernel. That way regardless of the command shell you used, programs could still use the service. But, I don’t think adding it to the kernel would be a very good idea. IDK. Guess I need to think on it more. :-) Jerome _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
