Subject: Type 3 Chinese Systems

From: Ng Liang Shing <[email-masked]>
Date: Fri, 15 Jul 1994 09:51:04 MYT

I have identified 3 types of Chinese systems, namely:

1. localised Chinese Operating Systems, with specific applications
   e.g. Microsoft Chinese Windows
2. standard (non-Chinese) O/S, patched with Chinese subsystems
   MS-Windows with CStar. Applications need not be specific

(note: specific means the applications are specially written for such a
Chinese systems. In Type 2, the Chinese patcher overrides the I/O subsystems
of the parent O/S, and 'forcing' Chinese services over ALL running
applications, whether or not the apps request for the Chinese services.)

3. standard (non-Chinese) O/S. Applications have Chinese functions built in.

Let's investigate what it takes to implement a Chinese systems, thus
justifying the pro's and con's of each type of these systems.

The fundamental part of a Chinese systems is very simple. It is the Chinese
Character Input and Output system. The Chinese Output system can be expressed
as:

     character codes ---( Chinese Output Systems )---> glyph data

The Chinese Input systems can be expressed as:

     key sequences   ---( Chinese Input Systems  )---> character code

The I/O systems can have very simple implementation up to very complicated
ones. However, for modest Chinese I/O functions, it does not take much to
implement.

So Chinese applications are indeed very simple. They are exactly same as all
standard (non-Chinese) programs, except that it request for Chinese functions
at some point of its lifetime.

It is the way services are requested and granted which differ in each type of
the systems. And this ultimately determines the complexity and stability (many
times they are inversely proportional to each other) of such a Chinese
systems.

1. In Type 1, the Chinese services are part of the O/S. There is often a
consistent set of API (application programming interface, i.e. how services
are requested and granted) to live with.

2. In Type 2, the patcher patches the parent O/S especially in the I/O
subsystem. In DOS, a Chinese patcher such as Eten will normally replace the
character I/O interrupt service routines (ISR) with its own ISR. The same idea
goes behind CStar and Windows.

3. In Type 3, the Chinese services are part of the application programs.

>From application programmers point of view:

Type 2 is a nightmare for application programmers. Patching the I/O subsystems
of the parent O/S often causes conflicts. A great deal of effort (indeed a
very great deal of effort) has been taken on the part of the Patcher developer
to minimise the conflict. However, some conflicts are fundamental.

I have met recently with two database application programmers. They both
develop programs using Eten on DOS. One of them uses Fox-pro, the other uses
Clipper.

The Fox-pro guy found major problem with loading his programs after
Eten is loaded - not enough conventional memory. So his solution was to sell a
ROM based version of Eten (with Eten card) to his customer. So I said this
added unneccessary cost on top of his software. But many would argue that such
cost will be paid by the customer anyway, so why bother? The trouble is what
if some one else produce a cheaper solution? A lower cost either mean the
product can be sold at a lower price and hence gain more market share OR the
product can be sold at the same price and hence increase the profit margin.
But at the moment, I have not seen an optimised solution as yet. So the
developer can sleep in peace for a while, but not too long.

The Clipper guy has problem with the Box characters. The internal clipper
dialogue box uses a ASCII box characters. They are interpretted as Chinese
character. In an intelligent mode (Z mode) Eten has added in its latest
version (not available in 3.0), the box character will be treated as box
character if 4 box characters occur consecutively. (This feature was
discovered but not documented). I think the logic behind is so that some
Chinese characters will be interpretted correctly. But it ultimately breaks
down when there exist two Chinese characters which are all made up of box
characters.

The Clipper guy also told me that he needed BOTH Jianti AND Fanti at the same
time.  But at the moment, Eten has only either Jianti OR Fanti version.  He
urged me to develop systems that works flexibly with both Jianti and Fanti (if
I am ever going to develop such a system)

So I would not encourage anybody who wish to write Chinese Apps for Type 2
systems.

We can see that although the applications gain some functions from using Eten,
at the same time, Eten has imposed many limits on them
1. memory
2. box characters
3. Jianti AND Fanti

I was worried about one potential problem. What happens when the programs are
networked (LAN or WAN)?  Will the Clipper network function conflict with Eten
network functions?  Suppose it won't, but it may take the programmers' a day
or two or may a week to fixed such problem.  And such difficulties in
maintenence ultimately means money and time.

And Eten only exist for DOS. It means the applications cannot be ported to
other O/S easily.

The Clipper guy was kind enough to lend me some of his documentations and
asked me to look into the possibility of interfacing his Clipper programs with
my Chinese functions which will be written in C. After some preliminary
investigations, I concluded that can be done without much trouble. The idea is
not to use Clippers own User Interface, because I will have to rewrite my own
anyway. My User Interface agent then communicates with the rest of his
programs by passing the essential variables. e.g. I capture the key sequence
and translate into Chinese character code, store it in some global variable,
then his clipper program picks up the characters. I retrieve data stored in
the global variable from his clipper program and translate them into screen
image.

Yours,
Liangsheng Wu

--
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.