Robert Platt escribió:
Well, as you suggest there would be a way to determine wether the codepage being used by the "system" and the codepage of the document match.Help is often run when the user is having problems setting up FreeDOS. Their codepage could be incorrect. Help should be robust in such circumstances. It would be great if I could detect the codepage, rather than assume it. Is there a DOS interrupt or something that could do this?
There are different components in the system that might unfortunately have different codepages (e.g. by using MODE CON CP SELECT=), but I guess you are asking mostly for the codepage of the CONsole, which is the codepage of the characters being displayed (and unless rare errors, the codepage of KEYB too).
The CONsole does not implement any codepage support in DOS kernel, unless you load DISPLAY.SYS (DISPLAY.COM still in FreeDOS), that implements codepage management for the console. You have the following interrupts in the DOS multiplexer (int2Fh):
AX=AD00h: DISPLAY.SYS installation check
AX=AD02h: DISPLAY.SYS get active codepage
These calls are implemented in FD DISPLAY. If DISPLAY is not present, you should almost certainly assume that the codepage is 437 (US/English).
You may find that there are other ways to obtain the system/kernel codepage (21h/6601h), but unfortunately the user may have called MODE CON CP SELECT=, and this codepage may differ from the CONsole codepage. In FreeDOS this will almost certainly occur, because we do not have NLSFUNC, which is the component that to some extent coordinates the codepage management.
Now, to guess the codepage of the document/string catalog, there's no way to do this for an arbitrary text file. IBM seemed that planned this for OS/2 and DOS 4.0, so that the file system would store the codepage of each file (for those files in which this makes sense), but this was, I think, never implemented (nor in DOS 5+). All that I am saying in this paragraph is mostly what I seem to recall from reading some books.
Yes. You could "force" the creators that one of the string variables is the codepage under which it has been programmed.Kitten: as I understand it then, the use of correct ASCII character codes is left up to those who create the catalogues - the program does not interfere with this and just treats the message return by kitten as plain text. Makes sense.
I don't know if I understand what you mean, but if you mean to map any-CP to current-CP, then mind that this problem doesn't have a good solution, just because some of the characters in the source codepage are not present in target codepage. Suppose that DISPLAY is not installed, thus current codepage is 437. Now if I write a message catalog using 850, and I use the character Á, this doesn't have any counterpart in CP 437...The kitten messages would hence not benefit from detecting the code page. That said, help could run the character entity parsing code on kitten messages. This would allow charater entities to be used in the kitten messages. Good/bad idea?
Unless you want to map not-found characters into a filled box or the like...
Henrique Peron may help you with this. I seem to recall a unix/linux utility called recode that may serve as source of information.Is there somewhere I can find an ASCII character map for each code page? It would save Eric the ordeal of sending me a transcription ;-)
Aitorç
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
