Hi Ladislav, > I think we should discuss how to implement unicode.
There already is some interface for double byte chars in DOS, which we could implement. However, it was made for Chinese as far as I remember and needed support by more drivers even if you had a DBCS-enabled DOS version. > In the fact only one small thing is necesarry: we need a mechanism > for translating unicode chars into ASCII chars and vice versa. Technically speaking, that translation is "char 0-7f of unicode are ASCII, the rest are not". What you probably mean is "for any _other_ unicode char, if char 80-ff of the current font codepage looks similar enough, display that char"... Which is very limited, given that unicode has 10000s of chars while any codepage only has max 128 non-ASCII chars for you. You could also support unicode for strings which are relevant for DOS... That would probably mean that you allow UTF8 in filenames. You could even use it without changing the kernel, if it is okay for you that search wildcards match a byte and not necessarily a character. The rest would depend on the ability of your CON driver to show UTF8 properly as far as the current font allows. You could even have a separately loaded CON driver that keeps a full unicode font in XMS (with some caching of recently used sections in faster memory maybe?). Note that many programs do not use CON, in particular if they want to have user interfaces with fancy layout. For example text editors do not normally use CON in DOS but you could have one which uses CON and needs NANSI. Actually you would want an UTF8-enabled super NANSI :-) > Now programs do it self by looking into own datafiles with .TBL > extension. Look at DOSLFN or Volkov commander 4.99. They have few > files like cp852uni.tbl, cp866uni.tbl and so on. As said above, that only allows you to display very few unicode chars - those which happen to be supported by your current codepage font. Still useful, of course. Be aware that UTF8 or unicode in general needs more bytes per character, so outside the LFN world, file names can reach their limit at less than 8+3 chars. But then, it is easy to load DOSLFN. > It is a very good solution but problem is that here is no > way now how to determine which file should be used. There is. DISPLAY has an interface to query the codepage. > It fully relies on manual configuration. See 2 lines above this. > Anothor point is that ASCII-unicode conversion should be somewhat > treated by OS, I think. I think it is not smart if every unicode > program has own TBL library. It should be one somewhere in FREEDOS > derectories. See above - but you could have some translation service. You could even have that UTF8 super NANSI described above but your soft then needs to understand the PRINCIPLE of UTF8. In other words, it has to understand in which way a sequence of two or more bytes can still mean only one character, which can be important for layout and search. > So how to solve it? > * let the user call function for international info, and by returned > codepage manualy decide which .TBL file to use? Such functions are available, yes. > * .TBL files should be in LANG or NLSPATH environment variable? Probably better to have a new variable for those, if any. > * somehow extend the kernel function for international info to say > which .TBL files to use? I would not put that in the kernel. Better in a driver. > * preload .TBL into memory in COUNTRY initialization and even more > extend international info to provide ASCII- unicode conversion? As above, if anything, this should be handled by a driver. Regards, Eric ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
