Hi Tom, > On Jul 19, 2021, at 2:49 AM, tom ehlert <t...@drivesnapshot.de> wrote: > [..] > your approach has has a deep disadvantage for programs like > Norton/Volkow/Midnight Commander, make utilities, etc. that shell out > to a new instance of command.com. > > they will start a new instance of %COMSPEC% with IMO no way of giving > it any arguments, so you would run the english version instead of the > localized one. > > I also see no 'numerous benefits'. a user that selects the dutch > localized version is unlikely to change this dynamically to russian. > > no problem though to have this as *option*. > > Tom
I apologize for not mentioning several points that should go along with the approach I suggest. I didn’t feel it was necessary to go into the minor details. To hopefully alleviate you concerns, I add a few things… First assuming there are translations available in a users preferred language, those versions are the message they should see. Regardless of how programs like EDIT, DOSSHELL and others invoke a sub shell. I have not studied the FreeCOM code. But, I assume it is smart enough to not keep multiple instances of itself in memory. That it detects previous instances of itself, then frees most or all of the memory consumed by a sub-shell. If that is the case, you would by default inherit the translations currently in use by the parent shell. Otherwise, if that cannot happen, there is a fairly simple remedy... When the first shell loads from the config file with a command like: shell=c:\freedos\bin\command.com c:\freedos\bin /e:1024 /p=c:\autoexec.bat /nls:c:\freedos\nls\command.es The shell would employ it’s magic to load the appropriate translations. But, it should also do one more important thing. It already sets the COMSPEC environment variable. It could easily preset the the LANG variable as well. Some English speaking users and probably all non-English speaking users already set this variable later in the AUTOEXEC file. So, it wouldn’t really be wasting environment variable space and would even remove the need for the user to remember to do it later. When any shell or sub-shell loads it can easily check for the LANG setting in the environment, then load those translations. In actuality, you could not bother with the command line option and just set the environment variable in the config file. But, I think the addition of the command line option is also a good idea, straight-forward and would take precedence over any LANG settings in the environment. However, if the FreeCOM just reuses pre-loaded code and data, it adds a some complications. If the user changes languages, then it should load the new translations. Then it would either need to just reference the new translations until the sub-shell terminated. Or, just keep a new instance of itself. Also, SYS should probably updated to also copy at least the copy the current translation along with the system files. Maybe, it could get an option like /COMBINED where it would copy FreeCOM replacing the default english language with the users preferred translations and produce a compact language specific version. This by itself would be a great alternative starting point and may be the easiest to implement. There are other minor things that will need to be considered. But, I think that covers most of the important stuff. A lot of it comes down to how the shell operates, uses memory and handles language translations in the first place. :-) Jerome _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
