Subject: Architecture of Chinese Character Input Output System

From: Ng Liang Shing <[email-masked]>
Date: Sun, 4 Sep 1994 06:34:44 MYT

Architecture of Chinese character input/output systems

Chinese character input/output systems include functions/algorithms for
translating device input (e.g. keystroke on keyboard) into Chinese character
code and functions/algorithms for translating Chinese character code into
device output (e.g. character on screen).

Here I attempt not to discuss how the I/O functions/algorithms are actually
implemented. Rather, I shall describe two classes of mechanism for interfacing
the I/O functions with application programs. I shall consider the problem
of how to call a Chinese character I/O function from an application program.

Invasive vs. Safe approach

The two classes of interfacing mechanism I wish to comment on are the invasive
and safe approach. They differ greatly in many ways and have advantages and
shortcomings in respective areas.

What I call the invasive approach is generally regarded as the 'normal'
approach or 'conventional' approach by many Chinese programmers and users,
because of its popularity.

Consider an example in DOS.  A program usually calls an interrupt service for
character I/O.  By default, the interrupt services provided by DOS or BIOS
would display ASCII (American Standard Characters for Information Interchange)
in text mode.  The trick is to 'intercept' the interrupt service routine for
character I/O.  A call is made to the Chinese character I/O functions instead
of the default character I/O functions.  This can be accomplished by simply
placing the address of the Chinese character I/O in the interrupt vector
table.

Other mechanism for 'intercepting' character I/O exists in DOS. The ultimate
in the art of interception exist at the memory level. Ultimately, BIOS or DOS
interrupt services write characters into the display memory area. The PC have
different display memory area for text and graphics. The first step is to
switch the display hardware into graphics mode, but fooling the running
application so that it thinks it is in text mode. So the usual character I/O
would write characters into the text display memory area. The intercepting
system interprets the content in the text memory then translate this into
Chinese character bitmap and write it to the graphics memory. Because the
display hardware is in graphics mode, the content in the text memory area will
not be displayed, but the content in the graphics memory area (Chinese
character bitmap) will be displayed.

Similar schemes exist for intercepting keystrokes to accomplish Chinese input
methods.

The safe approach is a much simpler and safer practice of programming. Here,
as constrast to the above example where the running application is not aware
of the presence of the Chinese systems, the running application makes explicit
calls to a well defined Chinese character I/O functions.

Consider examples in DOS again, the safe approach can be implemented in
several ways. One would be calling library functions. Alternatively, such
functions may be installed as an extra interrupt service routine (ISR), not
overriding the existing ASCII (text mode) character I/O ISR.

Advantages and shortcomings

This immediately brings out issues concerning the difficulties of
implementation and the benefits of information hiding.

The safe approach is easier to implement than the invasive approach obviously,
simply because function calls does not involve explicitly manipulating system
area (overriding the interrupt table in DOS, for example).

The invasive approach enjoys (?) the benefits of information hiding. Here, the
running application need not be aware of the presence of the Chinese systems.
Therefore, in DOS and other operating systems, some (but not all) existing
programs can be ported for Chinese use at binaries level. The safe approach,
however, is not directly portable at binaries level, though it is portable at
source level.

The benefits of information hiding explains the popularity of various invasive
Chinese systems in the DOS environment. Recently, intercepting capabilities
have been extended into Microsoft Windows environment and again has become a
popular choice.

The difficulty of implementation on the other hand may explain the absence
Chinese systems in other operating systems. (Note: While interception has
succeeded in Microsoft Windows, no interception is successful in X-Windows.
CXterm does not fall the category for invasive approach.)

Systems that are safe and also provides benefit of information hiding exists.
They are in quite difficult to implement because of the sheer scale of the
work involved in rewriting the interface system.

Examples

Name of System                       Approach  Comments

Microsoft Windows (Chinese version)   safe     safe because no interception.
                                               no interception because
                                               Chinese is default.
Mac OS (Chinese version)              safe     (same as above)
CXterm (Chines Xterm)                 safe     (same as above)
Eten                                  invasive    overriding BIOS ISR and
                                                  memory  (?)
ZWDOS                                 invasive    (?)
Chinese Star (for MS-Win)             invasive    intercepting Windows APIs.

Note: in above systems, running applications need not be aware of the presence
of the Chinese system

NJSTAR (for DOS)                      safe     calls to library functions (?)

Note: NJSTAR is an application program.

The future

Intercepting system area will be increasing difficult in robust operating
systems. Modern operating systems are towards this end. Hence invasive Chinese
system may dwindle with the end of the DOS era.

Fortunately, modern operating systems are towards multiligual interface (e.g.
adopting Unicode). This may provide both easy and safe programming approach
for Chinese character I/O. However, multiligual interface might not be
universally available or would come as an option with a higher price tag.

Safe approach with simple library function call can be an intermediate
approach until multiligual interface becomes widely available. It could also
lives on after that. In short, it has the strongest ability to survive. It is
a choice for the present and the future.

--
Ng Liang Shing            |   This is an Internet node host inside
Sungai Petani, Malaysia   |   an old 286.  A few years back, this place
[email-masked]          |   was not more than a small town.