*プロセス管理
ユーザー名、グループ名
P_USER
main(WORD ac,TCODE **argv);
prc_sts() プロセス状態の取り出し(実行ファイル名)
chg_usr() プロセスのユーザー情報の変更
get_usr() プロセスのユーザー情報の取り出し
グローバル名データ管理
cre_nam() グローバル名データの生成
del_nam() グローバル名データの削除
get_nam() グローバル名データの取り出し
*ファイル管理
ファイルシステムの情報 FS_STATE
ファイルシステム名
デバイス所在名
ファイルの所在情報 F_LOCATE
ファイルシステム名
デバイス所在名
論理デバイス名
ファイルシステム接続情報 F_ATTACH
接続名
リンクファイル情報 F_LINK
ファイル名
ファイルシステム名
デバイス所在名
リンク LINK
ファイル名
パス名
ファイルのユーザー名、グループ名 F_STATE
get_lnk() ファイルへのリンクの取り出し(パス名からリンク)
cre_fil() ファイルの生成
gen_fil() ファイルの直接生成
cre_lnk() リンクファイルの生成
fnd_lnk() リンクレコードの検索
cng_fnm() ファイル名の変更
fil_sts() ofl_sts() ファイル情報の取り出し
lnk_sts() リンクファイル情報の取り出し
syn_lnk() リンクファイルの同期
att_fls() ファイルシステムの接続(デバイス名、接続名、ファイルシステム名)
det_fls() ファイルシステムの切断
fls_sts() ファイルシステムの管理情報取りだし
chg_fls() ファイルシステム情報の変更
lst_fls() ファイルシステムのリストアップ
*イベント管理機能
キー入力用のイベント
EV_KEYDWN,EV_KEYUP,EV_AUTKEY
EVDATA.key
文字コード変換表 KEYTAB
get_ktb() 文字コード変換表の取り出し
set_ktb() 文字コード変換表の設定
*デバイス管理
デバイス名
デバイス情報 DEV_INFO
ユニット名
opn_dev() デバイスのオープン
chg_dmd() デバイスのアクセスモード変更
dev_sts() デバイスの管理情報の取り出し
get_dev() 論理デバイス名の取り出し
lst_dev() 登録済みデバイスの取り出し
*ディスプレイプリミティブ
描画環境
gopn_dev() デバイス描画環境の生成
gpon_mem() メモリ描画環境の生成
gget_spc() デバイス情報の取り出し
gget_dev() 対象デバイスの取り出し
文字(列)描画
gget_chw() 文字幅の取り出し
gget_chh() 文字高さの取り出し
gget_stw() 文字列幅の取り出し
gget_sth() 文字列高さの取り出し
gdra_chr() gdra_chp() 文字の描画
gdra_str() gdra_stp() 文字の描画
gcop_chr() 文字イメージの描画
私の考えた多国語化は、次のような物です。
API で使うコードは(1byte コードも入れた)TRONコードを使う。(固定長
文字コードではない)
システムとして、デフォルト言語を持つ。(実行中は変更不可)
プロセス・ウインドウ・描画環境ごとにデフォルト言語を持つ。(変更可)
文字列を使う場合、デフォルト言語のコードが使われる。
文字列の場合で、デフォルト言語以外のコードが使いたい場合、
言語指定コードを含めた文字列を使う。
1文字だけ使う場合、デフォルト言語のコードと見なす。
1文字だけ使う場合で、デフォルト言語以外のコードが使いたい場合の
方法がないので、デフォルト言語をあらかじめ変更しておく。
システム内部で持つデータはすべてシステムのデフォルト言語を用いる。
新たなウインドウが作られたとき、そのウインドウのデフォルト言語は
作ったプロセスのデフォルト言語を引き継ぐ。
描画環境のデフォルト言語は、ウインドウ描画のための物はウインドウの
デフォルト言語を引き継ぎ、その他の物は作成したプロセスのデフォルト
言語を引き継ぐ。
ウインドウ・パーツ・パネルについてはウインドウのデフォルト
言語を用い、描画関係は描画環境のデフォルト言語を用い、
その他の場合についてはプロセスのデフォルト言語を用いる。
この方法だと、従来のプログラムをあまり変更することなく
使うことが出来て良いと思います。
しかし、問題点もあります。
いちばんの問題が、1文字だけを用いる場合です。
デフォルト言語以外の言語を指定する方法がありません。
1つの関数で1つの文字だけを扱う場合なら何とかなりますが、
1つの関数で2つ以上の文字を扱う場合、それぞれの文字の言語を
区別する方法がなくなります。(もちろん言語指定のための引数を
増やせば出来ますが)
1つの関数で2つ以上の文字を扱う例としては、
2つの文字が同一の文字か・異形体か・別の文字かを判断する関数や、
ソートのために2つの文字の前後を判断する関数があります。
あと、依然としてアプリの方としても
固定長コードは扱いやすく魅力的ですので、
「TRONコードと固定長コードの両方の API を準備する」
と言う手もあります。
TRONコード⇔固定長コード 変換ライブラリを準備しておけばいいでしょう。
たしか、X の I18N に対応したヴィジェットは
4byte 固定長のコードを採用していたのではなかったでしょうか。
こちらも参考に出来ればと思います。
ちなみに、TRON協会のほうですでに多国語の扱いが決まっていたら
そちらを使うことになるので、この私の考えは意味がなくなります。
あしからず。
落合秀俊 名古屋大学工学部電気電子情報工学科
h953046b@ice.nuie.nagoya-u.ac.jp