Hi,
Robert Platt escribió:
>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?
>
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.
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.
>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.
>
Yes. You could "force" the creators that one of the string variables is
the codepage under which it has been programmed.
>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?
>
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...
Unless you want to map not-found characters into a filled box or the like...
>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 ;-)
>
Henrique Peron may help you with this. I seem to recall a unix/linux
utility called recode that may serve as source of information.
Aitorç
|