Hi Christian, > Just noticing that this grows quite large. If someone finds this > unbearable for this list, please speak up to let me know I should cut down > the off-topic stuff on my public mails!
No problem :-) I would hope that people talk more about the "big font" approaches - Having either a big Unicode font in XMS or maybe a 512 char double code page in the VGA card... Combined with, for example, a UTF-8 enabled Super-NANSI to make the step from strings to their display, of course. The problem would be loss of "ASCII" art block graphics in apps which are not using Unicode. A possible workaround would be dosver-style, to make a per-app decision who uses Unicode. I do not think that you could trust the data for this. Even on Linux where Unicode is quite common now, usage of BOM is rare. People try to keep their set of apps consistent to use either UTF-8 everywhere or Latin1 everywhere or (preferred) use whichever the LANG etc environment variables select at the moment when the app starts. Given that DOS has many old unmaintained apps, you will have to accept mixing in DOS: Some old apps will only use ASCII anyway which is the same for real ASCII and for UTF8 but some others will assume a codepage (often 437) to be active. The block graphics and other chars from the non-ASCII half of any codepage differ in encoding from UTF8 so, as said, any display or similar driver would need some way to switch between "classic code page mode" and "UTF8 rendering mode". It could switch on UTF8 based on explicit request from a modern app or based on app name for old but known compatible apps... It would switch off UTF8 when any app exits (int 21.4c / 21.31...). Compatible apps would be apps which only display ASCII out of themselves and which make no serious assumptions about one byte being equal to one character. A good example are MORE and TYPE: If you TYPE an UTF8 text with a special CON driver which expects and renders UTF8, it will simply work because TYPE passes the text file 1:1 and only uses plain ASCII for built-in messages, if any. A good counter example are PG and EDIT: They make the byte-is-character assumption for scrolling (in particular horizontal scrolling) and EDIT uses block graphics chars of codepages. So you have to put your CON driver in NON-Unicode mode while using EDIT or PG. As a general question - I would really like to know for WHICH APPS people want to have Unicode support. Is this only about proper display of playlists in MPXPLAY and of CD, USB or local accented filenames in any file manager? Is the issue also in general command.com style activity, probably depending on DOSLFN being present? If yes, I do assume that the LFN API already is explicit about whether UTF8 or rather codepage style encoding should be used? Are text editors also a case which should support Unicode and if yes, why do you not use for example Blocek then? Or is the idea to have "Unicode everywhere", even in the PrintScreen hotkey, TREE, Undelete, the volume label for SYS / FORMAT / VOL / LABEL, tools like FIND or DEBUG...? 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
