On 5/3/2023 12:29 PM, Aitor Santamaría wrote:
Hello!
Although I am some years late, my thoughts on this thread. By the way,
a very interesting thread on localisation for a hard case (the need
for DBCS).
Well,..
These thoughts are provided from the simple logic, not knowing about
DOS/V. In my understanding, supporting Japanese would *at least*
require the following functionalities, where the clue is given by
NLSFUNC/COUNTRY:
* Country settings (for date, currency, etc.), that should be easy.
That indeed would be the easy part. But...
* Collating/lowercase/uppercase tables, which in turn implies that
DBCS are handled where strings are handled, and my worry is about
filenames: how are filenames stored? how does it relate to 8.3
limitation, does it become 4.1 or does it require LFN...?
For one, as DOS/V would specifically apply to Japanese (but the same
would apply at least to Hangul (Korean) and Chinese), none of the script
systems being used (Katagana, Hiragana, and certainly not Kanji (Chinese
"characters")) has the concept of upper case/lower case...
* All character devices that currently support IOCTL, should support
this DBCS. As we have no PRINTER.SYS for PRN, we just need to focus on
CON:
- DISPLAY.SYS does not support DBCS, but I suppose that NNANSI
that is being discussed here will do the work. However:
- It would require KEYB to work with DBCS: this could work well:
+ if no codepage change is to be issued, DBCS can be outed
as "strings" by keyb (with an appropriate KL file)
+ if codepage changes is to be issued (because
NNANSI implements it), it should call KEYB
* Finally, non-console UI utilities should be made to work with DBCS:
this includes EDIT, INSTALL, ...
Ok, here is were that soft brown matter hits the fast rotating household
appliance. I am pretty sure that in order to create a DBCS version of
MS/PC-DOS, they did not use one and the same code base. Some basic DOS
function would have to be completely replaced with DBCS aware versions,
I don't think you can simply maintain dual-capable versions without
significantly increased memory requirements.
And most importantly, I don't think that we at FreeDOS have simply the
capacity to do any such adaptation. It would require AT LEAST one person
that is fluent in English and Japanese, as well as being sufficiently
proficient in programming. I don't think there is even remotely anyone
that could possibly fill that role within the current participants, nor
even lurkers, or they would be more active (and possibly proposing
required changes).
This would not only apply to adaptations to the before mentioned East
Asian languages and scripting systems, but also to things like
right-to-left systems like Arabic and Hebrew
(Urdu/Farsi/Pashto/Punjabi/Sindhi/etc)
Ralf
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
