図 7 UNIX のテキストファイルを Windows て儲いてみた (a) メモ帳ていたところ 万イ見化 ) 編集 ( 印検索 ) ヘルフ・せ $B : #F は 0 $ $ $ $ E75 $ $ G $ 9 ! ( h i s i s a t est f Ⅱ e fo 「 i ows. ー漢字コード : SJIS ー改彳丁コード : Enter 十 Newline ()R 十 LF) 漢字コードの違いは、英文であれは関係ありませんが、 漢字やかなを使う場合には避けようのない問題です。改行 コードの違いも避けられません 9 図 7 を見てください。これは、 UNIX (FreeBSD) 上 で作成した JIS コードによるテキストファイルを、 Win- dows のいくつかのエデイタで開いたところです。一番上 のメモ帳では、漢字も表示されていませんし、改行もされ ていません。その下のワードバッドでは、漢字は表示され ませんが、改行は正常におこなわれています。一番下は、 UNIX 上のエデイタである MuIe を Windows に移植し たもので開いています。さすがに、これを使えばそのまま 正しく表示されます ( もちろん編集もできます ) 。 UNIX と Windows 間のファイノい幻での間題を鮹夬 するには、改行コードと漢字コードの変換か必要です。も っとも簡単な方法は、 UNIX でも Windows でも Mule を使うことです。そうすれば、 UNIX でも Windows で もコードの違いを意識せすに文書が扱えてめでたいかぎ ・・と、これだけでは怒られそうなので、もうすこし ー殳的なな去を紹介しておきましよう。 UNIX 上のエデイタとして Mule を使っているのなら、 舌は簡単です。 MuIe はさまざまな漢字コードやテキスト 形式に対応しているので、その機能を利用すればいいでし よう。編集中のテキストファイルを変換するときは、、、 C - x C-k f" ( または SSM-x set-file-coding-system ' ) と 入力します 10 。すると、 ミニノヾッフアに FiIe—coding¯system: ■ monkey : それがやな、ちょっとの工夫で使えるように と表示されます ( 図 8-a)0 ここで、、 *sjis*dos" と入力 なるんや。いまから教えたるわ。 すると、そのバッフアのテキストファイルの漢字コード UNIX と Windows とのあいだでファイルを転送す は SJIS 、改行コードは Enter 十 Newline に変換され る際には、いくつか注意しなけれはならないことがありま ます ( モードラインの左側にある漢字コード表示が、、 J. " す。というのも、 UNIX と Windows ではテキストファ から、、 S : " に変わります ) 。この状態で保存すると、 Win- イルの扱いに違う点があるからです。簡単にまとめると次 dows て読み書きできるテキスト形式になります。 のようになります。 9 Mac OS ク足攵行コードは、 UNIX とも Windows とも違い、 Enter ・ UNIX のテキストファイル (CR) のみてす。それぞれに青があるのでしようが、頂襾にすオ ー漢字コード : JIS 、 SJIS 、 EUC 10 C-key は Control キーを押しながらん ey を押す、 M-key は Meta キーを押しながらんを押すことを示します。 Meta キーのないキー ー改彳丁コード : NewIine (LF) ポードでは、 ESC キーを押しそのあとにん e を押すことに用でき ・ Windows (DOS) のテキストファイル ます。 ロ X ロリ n 明ⅸい・メモ (b) ワードバッドて儲いたと ころ ファイルの編集 ) 表示Ⅳ ) 挿入 ( P 書式 0 ) フ。但 ) Th i s i s a test f Ⅱ e for i ndows ・ $B # F は 0 $ $ $ $ E75 $ $ G $ 9 ・旧 Ft 押すとう表黛ます。 (c) 、 Vindows 上の Mule て開いたところ Th1S IS a test file for Windows. 今日はいい天気です。 同ロ 自・」。いを・一ワ斗元外。 N リ柄 物同ロー ( F リい d 田 nt- ュ 1 ) ーーゑ 1 1 ー ー M 1 を : 1 」れ 1 m 」 g . t : ( t 図 8 Mule で漢字と改行コード変換 (a) set-file-coding-system の実行 This a test file for 』 s. きようはいい天気てす。 一三ロ 巨 L 廴亡 : し ! E 」にを . 気 e—CÜ•d1n&-systen: *sous*do (b) *sjis*dos に変更してみる Th1S a test file fo ェ oys. うはいしてす。 18 UNIX MAGAZINE 1997.10

このようにして作成して保存したファイルを Windows 側にもっていけは、メモ帳などを使ってそのまま編集でき ます。 MuIe は、数多くの漢字コードや改行コードに対応 しています。 ニノヾッフアに File-coding-system: ' と 表示されたところで TAB キーを入力すると、指定できる すべての形式が表示されますから、一度見ておくといいで ます。 漢字コ しよう。 この機能を使えば、 UNIX と Windows とのテキ ードは、この一覧のなかでは、、 *junet*" に相当し インターネット上でもっともよく使われている UNIX MAGAZINE 1997 ユ 0 あるけど。 あつぶる : たしかに、あんまり親切すぎるのも困るときが ちょっと手間がかかるんやけど。 ントを読んだかぎりでは、でけへんようや。そやから、 monkey : できても不思議はないんやけどな。ドキュメ あつぶる . samba が自重加勺にやってくれればいいのにれ しがたいな。 文字コードはしゃあないけど、改行コードはいかんとも monkey : ちっとは苦労せえへんと、っちゅうことやな。 るわね。 あつぶる : できた、できた。でも、ちょっと手間がかか monkey : これで一丁上がりや。 の課題ということで・・・・・・ ) 。 にも便利なプログラムがあるかもしれません ( それは今後 といったところかオ剽勺なガ去でしよう。もちろん、ほか ・ Windows 上で変更する場合は Mule か nkf を使う ・ UNIX 上で変更する場合は MuIe を使う ファイルの変換ガ去について簡単にまとめると、 コードも変換してくれます。 一方、 DOS 用の nkf では、漢字コードとともに改行・ 一気に削除するといった処理が必要です。 示されます ) を削除するか、 sed などのコマンドを使って 工デイタなどで不要な予コード ( 画面中には ~ M " と表 にもってきた場合は、 nkf で漢字コードを変換し、その後 ませんでした。 Windows 上で作成したファイルを UNIX がら、改行コードの変更までしてくれるツールはみつかり ていれば、漢字コードの変換は簡単です。しかし、残念な あります。 UNIX 上に nkf コマンドがインストールされ テキストファイル形式を変換するガ去は、これ以外にも ストファイルの扱いの違いなど、怖くはありません。 おうちでらんラン LAN 第 6 回 monkey : そらそうや。そういえは、 UNIX の mtools っ ちゅうパッケージやったら、フロッピー経由でⅥⅲト dows とファイルのやりとりができるけど、これには改 行コードの自動変換機能がある。 あつぶる : そういうのもあるんだね。 monkey : オプションて指定するんやけどな。そやけど、 山も丘はフロッピーもあんまり使わんしな。 あつぶる : でも、ときどき使ってるしゃない ? monkey : ああ、あれはえっちなファイルをを上とやり monkey : あー、もう、なんやこル samba 以外での交換 monkey : 魔がさしただけでございます。お、 したんや ? あつぶる : おうおう、そこのにいちゃん、いま、何ぬか とりするときに お許し 19 嫌い " という場合には、 samba 以、タ ) ガ去でファイルを転 samba かイ吏えなくなったり、あるいは、、 GUI なんて大 monkey : は、ほんの出来じ、です。お許しを・・ そんなことしてたんやな ! ! あつぶる : おっさん、何言うてんねん。わしのときにも、 ときに別の子とちょっとデート・ monkey : そうや。ゆうたら、本命の彼女に会われへん なら ftp でできるのね。 に samba が使えなくなったときも、ファイル転送だけ あつぶる : ふーん、そうなのか。じゃあ、なにかの拍子 んと ftp コマンドが用意されてるからな。 monkey : できんでかいな。 Windows 95 からは、ちゃ あつぶる : そんなことできるの ? ファイル転送したろ。 から、よけいにそう感しるんやろな。 samba 使わんと、 monkey : ふだん、 UNIX でコマンド行から操作してる あっぷる : そうかしら。 いらするわ。 のもええんやけど、なんやかえって日判肋ゞかかっていら 持ってきてんねんけど、どうもいかん。 GUI っちゅう monkey : ん一、 samba 使うて Windows にファイル の血管が切れちゃうわよ。 あつぶる : あらあら、そんなに真っ赤になってると、頭

Java & C 十十■ 図 1 C 十十のクラスを Java に取り込む手順 Circle.ja 、 ー avac javah Circle. class -stubs Circle. h Circle.c drawimpl.cpp C 十十コン / ヾイラ drawimpl.dll loadLibrary #include "circle . h" int Circ1e : :radius() { return _radius ; Java からこのコードを利用するには、このクラスのた めのコードを含む共有ライプラリが必要である。この例で は、コードをすべてヘッダファイルに↑褓内できるが、通常 はこれ以外のソースコードもあるはずだ。 solaris 2. x の Sun SPARCompiler C 十十 4. x を用 いて、このクラスを共有ライプラリにコンパイルするため CCOPT = —I . —G —Kpic CCC = CC # Makefi1e の Makefile は次のようになる。 言したプログラミング・インターフェイスをもつ Java ク る Java API の作成が目標なので、同じ public として宣 ンターフェイスの言である。 C 十十 API のようにみえ これで C 十十ライプラリができた。次は、 Javapeer イ libcircle. so が生成される。 コマンド行から make と入力すると、共有ライプラリ $(CCC) $(CCOPT) circle . cc ー 0 libcircle . so libcircle . so: circle . CC circle . 五 84 ラスが必要である。 * Circ1e クラス : C + + のクラス Circ1e の * ための peer クラス public class Circ1e extends CppPeer{ public native int radius ( ) ; private final native void —newCirc1e (int r) ; public Circ1e (int r) { super() ; newCirc1e(r) ; static { 10ad("Circ1eImp") ; C 十十の場合と同様、この Java クラスの public メソッ ドでは、 radius() は int を返し、コンストラクタ Circle() は int をとる。 radius() メソッドの実装は未定義のまま である。 Java のキーワード native は、ネイテイプコード として実装されることを表す。 Java 言語では、ネイティ プなコンストラクタは認められていない。そこで、プライ べートなネイテイプ・メソッドを呼び出す Java のコンス トラクタを定義しなけれはならない。このコンストラクタ は、 C 十十の new 演算子を用いて C 十十クラスのインス タンスを生成し、 CppPeer で定義する -cppPtr フィール ドに、この新たに割り当てられたオプジェクトのアドレス を代入する。最後に、 static{ } の部分で、さきはど作成 した Circle 共有ライプラリと、このあとで定義するコン パイル済みのスタブコードをロードする。このコードは、 Java クラスが JVM (Java Virtual Machine) にロード されるときに 1 回だけ実行される。 このクラスを、 Sun の標準 JDK にある Java コンパ イラの javac を用いて JVM バイトコードにコンパイルす る。そのための MakefiIe のエントリは次のようになる。 CircIe. class: Circ1e. java Javac Circ1e. java 次に c 十十ライプラリの適切なメソッドを呼び出し、 Circle. java で定義したネイテイプ・メソッドを実行する スタブコードを書く。 Java では、ネイテイプ・メソッドの呼出しに名前変換 (name-mangling) 方式といくぶん定型化された wrap- per コードを利用するため、 Java クラスファイルのネイ テイプ・メソッド旦言にもとづいて、 wrapper と変換され た名前を生成するツール javah カ甘是供されている。 javah UNIX MAGAZINE 1997.10

Java & C 十十■ ご覧のように、構文は簡潔である。簡潔さは強力なツールにな るので、長々しくすべきではない。ークラスのコードか数彳丁 以 . E にわたるようなら、一殳にそれを名前付きクラス ( 内部ク ラスであそオび 19 ) クラスであれ ) にすべきだろう。 内部クラスの入れ子を重ねすぎるのも避けるべきである。何 のなかに何が入れ子になっているのかが分からないような複雑 なコードを読み解くのは難しいからである。ーイ殳に、内部クラ スの闢則に別の内部クラスを作るのは避けたはうがよい。 オプジェクトの直列化 (serialization) は、 java. io パッ ケージの新しい部分である。これによって、オプジェクトやオ プジェクトのグラフをストリームに書き、生成されたバイト列 から等価なオプジェクトやグラフを再構成できるようになる。 直列化を可能にするためには、オプジェクトカ啌の Serializ- able インターフェイスを実装しなければならない。デフォル トの手順では、オプジェクトのフィールドのうち、 static と transient のものを除くすべてを一度に滷列化する。クラスは、 必要ならこの重川第を無効にできる。オプジェクトの直列化によ り、状態の保存や復元のための基本的なツールカ甘当共される。 どのようなクラスも、直列化できるようにしておくべきである。 そうすれは、それを必要とするアプリケーションのために利用 できる。 RMI 新しい RMI (Remote Method lnvocation : リモートメ ソッド呼出し ) パッケージの java. rmi により、別のホスト上 で実行されるコードや、はかの JVM で実行される Java コー ドから呼び出せるオプジェクトが生成できる。 RMI は、 Java どうしの通信を頁においたものであり、いくつかの Java 特 有の機能を活用できる。言語を中心に作業が単純化されるとい うメリットだけではなく、 RMI には、クライアントやサー ーがこれまで遭遇したことのない型のオプジェクトであって も、そのオプジェクトの受け渡しができるという大きな特徴が ある。仮に一方にとって未知の型をやりとりしたとしても、そ のクラスの Java コードのダウンロードや利用は可能である。 ダウンロードされたコードは、アフレットと同様に、セキュリ ティ・サンドボックスで包むことができる。 RMI は Java のみで日当された環境で作業できるよう言妬 されており、このようなホモジニアスな工竟でのみ作業が可能 である。 Java 以外のシステムとの直接の通信はサポートしな い。 RMI は、パラメータの整列の際にオプジェクトの直列化 を用いる。これが、 SeriaIizabIe クラスを生成するもう 1 つ の理由である。 その他の特徴 新パッケージ java ・ security は、署名ペ引普号化などのセキュ リティ里の要求に対応したクラスやインターフェイスを提供 する。これらを用いて Java アーカイプ (JAR) ファイルに署 名し、利用者がコード配布者を石忍する手段として利用できる。 これらの署名入りコードでは、プラウサは、署名入りアプレッ 94 トがローカルのリソースへアクセスしやすくするために、より 柔軟なセキュリティ・モデルを利用するだろう。たとえは、あ なたの会社がその内部アプレットに署名し、署名入り内部アプ レットにローカル・ネットワークからのアクセスを認めるよう にプラウザのセキュリティを設定するといったことが考えられ る。コード署名により、そのコードの署名者を担纒こした多様 な信用レベルか利用できるようになる。 JavaBeans API は、 Java コンポーネントを構成する方 法を提供する。 Java Beans は関係していない開発者がエンド ューザー・ツールで統合できる Java コンホーネントを書いた り送り込んだりできるソフトウェア・コンポーネントである。 java. beans パッケージは、この強力な新機能に対応する API を提供している。 以ード、その他の新しいパッケージをいくつカ召介しよう。 ・ java. lang. reflect このパッケージは、そのクラス言当からオプジェクトを参 照したり操作するためのものである。 ・ java. math このパッケージは、算術操作のためのツールを提供する。 現在、 BigInteger クラスが任意精度整数演算を提供し、 BigDecimal カ壬意精度の 10 進寅算を提供している。 ・ java. sql このパッケージは、リレーショナノレ・データベースを利用す るためのべンダーに依存しない JDBC (Java DataBase Connectivity) ツールを孑是供する。 ・ java. util.zip このパッケージは、 ZIP ファイルを扱うためのものである。 JDK 1.1 は、 Java アプリケーションやアプレット、その 他の Java コードを書くための基本的な機能を強化したもので ある。互換性は高く、新機能は麦もプラットホームを選ばな いコードを書くうえで、プログラマーの助けになるだろう。 Sun Microsystems のスタッフ・エンジニア。 JavaSoft で 分散型コンピューティングを担当。実践的オプジェクト指向 言 t や実装に関するエキスパートである。カリフォルニア大学 バークレイ校で 4BSD チームに参加し、在学中に curses ラ イプラリ・パッケージを作成。 rogue の開発にも携わった。 James Gosling との共著に『 The Java Programming LanguageJ (Addison-Wesley, 1996 ) がある。 ・ Ken Arnold UNIX MAGAZINE 1997.10

図 9 ftp コマンドのパイナリモードとアスキーモード UNIX HOW are you? lt's fine today. HOW are you?AM lt's fine today. AM HOW are you? lt's fine today. 送しなくてはなりません。 升 p コマンドで転送 ノヾイナリモード ( そのまま転送 ) アスキーモード ( 改行コードを変換 ) UNIX の世界でのファイル転送の標ま勺なプロトコル は FTP (File Transfer Protocol) です。そして、この プロトコルを使ってファイルを中幻医するプログラムが代 p ですね。皆さんも、きっと使ったことがあるでしよう。 ftp コマンドは、 Windows 95 にも伺属していますい 般に C:YWINDOWS ディレクトリにあります ) 。これを 利用すれば、 UNIX とのあいだでファイルのやりとりがで きます。ただし、 UNIX から Windows に対して ftp コ マンドを実行することはできません。これは、 Windows 95 に FTP サーバーの機能がないからです。 Windows に付属の仕 p コマンドは、 UNIX のものとはとんど変わ らない機能をもっているので、 UNIX 上で ftp コマンド を使った経験のある人なら、はとんど違和感なく利用でき るでしよう。 ftp コマンドでは、漢字コードの間題は残るものの、転 送モードを適切に設定すれは改行コードの問題を鮹夬する ことができます。 ftp コマンドでのファイル転送には、、アスキー " モー ドと、、バイナリ " モードがあります。前者は、テキストフ ァイルに関する処理を施しながら輔医します。後者はバイ ナリデータを送るためのモードで、ファイルをそのまま転 送します。もちろん、バイナリモードでテキストファイル を中幻医することもできます。 UNIX システムどうしでファ イルをやりとりする場合は、すべてバイナリモードで転送 20 Windows 95 HOW al ℃ you?l lt's fine today. HOW are you? lt's fine today. HOW are YOII? lt's fine today. してもなんの間題もありません。 Windows の ftp コマンドを用いて UNIX とテキスト ファイルをやりとりするときは、アスキーモードを利用す るといいでしよう。アスキーモードて沖幻医すれば、 ( 漢字 コードはそのままですが ) 改行コードを正しく変換してく れるからです。バイナリモードで転送すると、 samba の ときと同改行コードは変換してくれません ( 図 9 ) 。 ftp コマンドでのアスキーモードとバイナリモードの別 は、相手に接続してから次のように設定します。 C:*> ftp umpc Connected tO umpc 220 umpc FTP server (Version 6.00 ) ready. Name (umpc: (none)) : monkey ←ユーサー名 331 Password required fo て monkey. Password: umpc でのノヾスワード 230 User monkey logged in ・ ftp> ascii ←アスキーモードへ 200 Type set to A. イナリモードへ ftp> binary ←ノヾ 200 Type set to I . ftp> ロ (get や put などで転送 ) ftp> quit 221 Goodbye. ascii 、 binary の部分は、それぞれ、、 as" と、、 bi" とだけ タイプしてもかまいません。 こうしてアスキーモードにしておいてからテキストファ イルを転送すれは、改行コードを変換する手間が省けま UNIX MAGAZINE 1997.10

Java & C 十十■ かもしれない。だが、この技術には重大な間題がある。利 ル ) を読み取り、できるかぎりオリジナルの C 十十 API 用する C 十十のコードが ActiveX コンポーネントとして に近い Java API 、つまりオリジナルの C 十十コードへ パッケージ化されていなければ、うんざりするような竹喋 の Java インターフェイスを生成する。したがって、 Java を強いられるし、 COM インターフェイスの制約によっ のプログラミングにおいては、 C 十十のライプラリを Java て、 ActiveX コンホーネントを Java に導入する際、少 で書かれたものであるかのように利用すれは・よい。 Twin- なからぬ数の機能を生にせざるをえなくなる。 peaks では、あらかじめ 2 つの言語の機能を対応させてお くので、オリジナルの C 十十のドキュメントを読み、 Java さらに、 ActiveX と Java とのあいだのインターフェ への単純な変換ルールを適用するだけで、 TwinPeaks が イスは Windows でしか使えす、 UNIX や Macintosh 、 生成した API を簡単に使用できる。 TwinPeaks のアプ メインフレームのプラットホームには対応していない。た ローチについては彳あ主する。 とえ W ⅲ dows 上であっても、 ActiveX コンホーネント としてパッケージされたユーサー・インターフェイスのた TwinPeaks は、分昔ではなく、いわはシングルプロ めのコントロールと、標準の Java グラフィックス・ライ セス方式の手法である。言い換えれば、 TwinPeaks を利 プラリ (AWT) を使う Java コードとの結合は容易ではな 用する C 十十ライプラリや Java のコードは、同じマシン い。 Java と Microsoft のスクリプト言語 VBScript と 上で実行されなくてはならない。というより、これらは同 を結びつける複雑なイ′ド業カ球められるからだ。 Microsoft じプロセスにリンクされている必喫がある。これは、配布 は、 Java で DCOM (Distributed Component Object する際の缶齣になる。さらに、 C 十十のネイテイプコード Model) を扱うための一定のサポートをおこなってはいる が Java のコードとともに実行されるため、 TwinPeaks が、 ActiveX のプリッジは JNI を用いた手法と同様、本 を用いるアプリケーションは、純正の Java アフレットの 質的にネットワーク化されたものではなく、シングルプロ ようにインターネット上で簡単にダウンロードできない。 セス方式である。 しかし、大部分のサーバー側アプリケーションでは、 れらの間題ば架刻なものではない。 TwinPeaks は、継承 ネットワーク化されたアプリケーションの多くは、よ り軽いクライアント・プロセスと↑帯長のやりとりをするサ した C 十十コードを再利用したり、 Java に相当する機能 ーバープロセスとして構成される。サーノヾープロセスのは がないようなサードバーティー製の C 十十ライプラリにア うはモノリシックで、単一のプラットホームで動き、パ クセスしたり、あるいは、アプリケーションに不可欠の フォーマンスが重視される。これを、多層型 (multitier) 低レベルな部分を C 十十で書き、 Java から呼び出したり するときの有効な手段となる可能性がある。現在、 Sun- アーキテクチャと呼ぶ。今日では、サーバープロセスは Soft は TwinPeaks をベータテスト中である ( 詳細は、 ( 効率的な ) C 十十で、 ( あらゆるプラットホーム上で、し かもたいていは Web プラウザから実行される ) クライア twinpeaks-request@sunpro ・ eng ・ sun.com にメーノレで ント・プロセスは Java で実装することか意味をもち始め 問合せのこと ) 。 ている。上に述べたようなシングルプロセス方式では、開 Microsoft は、 Java コードと外部コンホーネントをリ 発者はネットワークから Java のみで記述されたダウン ンクさせる手法として Java.COM 接続を提唱している ロード可能なアプレットを作成できない。このような方式 ( http://www.microsoft.com/visualj/docs/vjcom は、あらかしめ決められた 1 つのホスト上で実行する従来 SIBDC6. HTM)O これは、 ActiveX コンポーネントを のアプリケーションに適している。 Java のクラスであるかのように Java にインポートし、 多言語コンポーネントの配布によく使われるのが、高レ Java のクラスを ActiveX コンポーネントとして工クス ベルのサービスセット CORBA (Common Object Re- ポートするものである。このガ去は一見魅力的である。数 quest Broker Architecture) である。 CORBA には、 多くの ActiveX コンホーネントカイ吏えるし、 ActiveX コ ソフトウェア・コンポーネントを実装する言語に依存せす ンポーネントは C 十十を含めて Microsoft がサポートす に記述するためのインターフェイス記述言語 (IDL : ln- るどの言語でも書けるからである。 Java から ActiveX コ terface Description Language) 、 ミドルウェア通信フ。 ンポーネントにアクセスするのが目的なら、想的な手法 82 UNIX MAGAZINE 1997.10

連載 /FreeBSD ノートー① 変数を設けて、同時に複数のプロセスがカーネル内のコー ドを実行しても、 critical region を実行するプロセスは 1 つだけに制限するというものである。 nonpreemptive なカーネルでは、排他制彳卸する単位は カーネル本なのて粒度はもっとも粗いものだったが、新 しい同期のオではより細かい粒度て制御しているという ことになる。 粒度か細かいはど CPU の有効な利用か期待できるが、 処理のオーバーヘッドは大きくなる。実際のカーネルで は、そのトレードオフのバランスをとる必喫がある。 ℃ eBSD の SMP 対応 FreeBSD のようなイ充的な構造の OS に、この排他制 御を導入するのは難しい。もともと FreeBSD は、排他制 御の必要がないというⅲ胱のもとに言 t されている。その ような OS のコードを見直して、必要な部分に排他缶衂を 加えるのは大変な竹喋である。 FreeBSD の SMP 対応で は、この間題をかなり乱暴な去て痾夬している。 FreeBSD では、カーネル内のコードを同時に実行でき るプロセスを 1 つに限ることでカーネルか排他制彳卸を必要 としない ( すなわち、イ充的なカーネルのコードがそのま ま流用できる ) 力法をとっている。これは、 nonpreemp- tive なマルチタスクを SMP に刻長したことに相当する。 この方法の最大の欠点は、カーネルの実行が 1 つのプロ セスに限られてしまうことである。つまり、あるプロセス がシステムコールを実行しているあいだは、ほかのプロセ スはシステムコールを実行できないので、その他の CPU は待っていなけれはならない。 前回紹介したように、カーネルを make する実験では、 2CPU で ICPU 時の 1.9 倍というほは想的な処理速 度を得ることができた。次々にプログラムをコンパイルす るような処理では、カーネルのコードを実行するのは最初 のデータの言もムみと最後の書出しくらいである。これは全 体の処堋りからするとごくわすかで、それ以外の時間は CPU がユーサー空間で動いて鏘訳をおこなっている。 のようにプログラムカ艘数動く場合は、 FreeBSD のよう に粒度のごく粗い SMP 対応でも効率よく実行できる。 しかし、カーネルのコードカ噸繁に実行される場合は効 率か期待できない。たとえば FreeBSD の NFS サーバ ーは、デーモンプロセスとして複数起動されるが、実際の 118 コードはカーネル内に実装されている。この場合、複数の デーモンか 1 司時に処理をおこなえれは SMP の利点か活か せるのだが、 FreeBSD では 1 度に 1 つしか実行できない ので CPU を増やしたメリットがない。さらに、 SMP 対 応のためのオーバーヘッドを考慮すると、 NFS サー としての性能は ICPU 時よりも低下してしまう。 このような大きな欠点のため、 FreeBSD の SMP 対 応は実験レベルと考えるべきである。本来、 PC の SMP マシンやマサーポードはサーバー用として用意されている が、 FreeBSD で利用する場合は注意が必要である。 SMP 対応つ将来 粒度のさらに細かい SMP 対応を提供するのが、なんと いっても最大の言題である。たとえば、ローカルディスク などのストレージへのアクセスとネットワークへのアクセ スは基本的に衝突しないので、それぞれのカーネルコード を 2 つのプロセスか 1 司時に利用するようにしても大丈夫な はすである。こういう分析を進めて排他制御の範囲を狭め る、すなわち粒度を細かくしていくことが考えられる。 しかし、この作業は前述のようにかなり大変である。 FreeBSD プロジェクトは、有志のあいだのゆるやかなっ ながりによって運営されているので、こういった大掛りな 竹業を実行できるのかどうか、正直なところかなり疑間で ある。また、仮にそオ功ゞ可能だったとしても、 BSD 系の 旧いアーキテクチャの OS にそれた、けの労力を注ぎ込む意 義があるのかどうカ考慮する必要があるだろう。 個知勺には、 SMP のような新しいアーキテクチャへの 対応は GNU OS などの新しい OS に缶て、 FreeBSD は従来の BSD の世界をより洗練させる方向で開発を進 める、といったぐあいに棲み分けを図るのがよいのではな いかと思っている。そして、引絲冬的にば東された BSD 流の設計思想カ噺しい OS に受け継がれることにより、 FreeBSD はその役割を終えるのではないかと夢想してい UNIX MAGAZINE 1997.10 ( はまだ・なおき ) 次回は、 FreeBSD を利用したモバイル IP の利用例を ☆ もちろんそんな先のことは分からない。 紹介する。 るのだが、

DAEM 〇 NS & DRAG 日 CS によるシ •Dinah McNutt NS 朝 テムファイルの管理 システムファイルの変更を追いかけるのは、面倒な作 業である。いつ、どんな変更がおこなわれたかを把握す るのに、多くの管理者は自分の記慮を頼りにしている。 システムファイルに対する変更は、概して構成管理と 関係している。たとえば、ログインできるユーザーの変 更などはシステムの動作に影響を - 学える。システム設定 ファイルの多くは、単純なテキストファイルである。し たがって、システムの変更を追いかけたり、同時に複数 の人間が同しファイルを編集するのを防ぐには、 RCS (Revision control System) や SCCS (Source C0de Control System) などのソースコードを管理するため のソフトウェアか役に立つ場合がある。ソースコードの 管理にサードバーティーのソフトウェアを購入したくな いサイトにとって、 RCS はいい解決策だろう。今回は、 RCS の利用法や、 RCS およひ類イ以のプログラムの入手 方法などを紹介する。詳しく説明するのは RCS だけで ここで示す概念はすべてのソースコード管理フ あるが、 ログラムにあてはまる。 RCS の基本 RCS を有効に使うには、いくっかのコマンドを憶え るだけでいい。初めに、ソースファイルがあるディレク トリごとに RCS というサプディレクトリを作成する。 この作業は必須ではないが、 RCS 関連のファイルをす べてこの RCS ディレクトリに保存することができる。 さらに、ディレクトリの内容をリストするだけで、どの ファイルカ壻理されているのかが一一目瞭然になる。 % Ci —u . cshrc RCS/ . cshrc,v く一 110 . CShrc from UNIX REVIEW このコマンドはファイルに対してチェックインをおこ ない、ファイルはロックされすにディレクトリに置かれ る。デフォルトではファイルのコピーは作らない。ファ ミッションは読出し専用になる。初めてチェ イノレのノヾー ックインをおこなう場合、ファイルに関する説明を記述 こでは、無意味 するためのプロンプトが表示される。 な説明を書くべきではない。ファイルの書込みは禁止さ れるが、読出しと実行の権限はそのままである 1 。 % co ー 1 . cshrc RCS/. cshrc,v . cshrc revision 1 . 1 (locked) done enter description, terminated vith single ' . ' or end of file: NOTE: This is NOT the 10g message ! > > My personal . cshrc file initial revision: 1 . 1 done 上記のコマンドはファイルに対してチェックアウトを おこない、書込み可能な状態にする。はかのユーザーが チェックアウト ( あるいはチェックイン ) しようとする と、ファイルがロックされている旨のメッセージを受け 取るだろう。この機能によって、はかのユーサーが同時 に同しファイルを変更できないようになっている。 ファイルを適当に変更したら、以下のように実行すれ ばチェックインがおこなえる。 % Ci —u . cshrc RCS/ . cshrc ,v く一 . cshrc new revision: 1 . 2 ; 1 . 1 1 ⅵコマンドのタイプミスを防ぐために ci という工イリアスを定し ているなら、その設定はやめたはうがよい。 UNIX MAGAZINE 1997.10

Java & C 十十■ JDK 1 . 1 ー Ken Arnold ラスを用いてローカライズされるようになっている。従来の JDK (Java DeveIopment Kit) 1.1 の改良点は、おも PrintStream クラスは、置き換えられた。 に国ドヒとネイテイプ・メソッドを書くための新しい API で もう 1 つの国月題が、ローカライゼーション ( ル或イり ある AWT (Abstract Windowing TooIkit) の拡張が中 である。新しい java. text パッケージでは、ローカライズされ 心である。 JavaBeans 、セキュリティ・ツール、丿鬲手続き たメッセージの入出力かできる。さらに、ロケールに依存する 呼出しなど、いくっかの新しい技術も導入されている。そのほ こで 文字列や日付などの照合を扱うガ去も提供している。 か、 Java 言語自体にも若千の変更カ功日えられている。 は、変点や互換性に関する問題の概要を紹介する。譖田は、 本文で言及されている新しいネイテイプ・メソッド API が http://java.sun.com/products/jdk/l.1/を参照のこと。 追加されたのは、 API を正規化し、より優れた抽象化機能を もっとも重要なのは、 Java 1.1 Virtual Machine (JVM) JVM に提供するためである。 1.0 のネイテイプ・メソッド が、 JDK 1.0.2 用にコンパイルされたコードと完全に互性 API は内部構造か露わになりすぎていて、ガべージ・コレク を保っている点である。 JVM に加えられた変更は、すべて性 ションやメモリの利用の効率化といった多くの重要かっ有用な 能や品質、柔軟性を向上させるためのものである。要するに、 JVM 実装を妨げる要因になっていた。 バイナリの互換性は糸財寺されているということだ。 冒ロ文冒十 新しい API の大きな特徴は、テフ。リケーション (depre- cation) である。識別子のドキュメント・コメントに@dep- 言語に関するおもな新機能は内部クラスである。これによ recated タグを付けて、クラスやインターフェイス、フィール り、クラスやインターフェイスをほかのクラスのメンバーとし ド、手続きか置き換えられたものとしてマークできる。これら て定義できるようになった。入れ子になったクラスは、自身 のタグには、どの機能がどの関数と置き換わるのかカ己され を囲むクラスの実装の一 - 一部を友している。タ M 則のプライベー ていなければならない。置き換えられたクラスやインターフェ トなメンバーへのアクセスが可能で、さらにそれ自体をプライ イスを使うプログラムをコンパイルすることはできるが、同時 べートなものとして扱うことかできる。たとえば 1.0 では、コ に、必要な書換え作業をおこなうようにプログラマーにアドバ ンテナの内容を列挙するオプジェクトはトップレベルのクラス イスする警告を生成する。これによって、既存のコードを無馮太 となっていなけれは・ならない。そして、できることといえば、 にすることなく、日赫にに合わせて自分の API を進化させたり、 内容を取り出すオプジェクトをパッケージ・アクセスが可能な 状況に応じて変更できる。 クラスとして、コンテナをそのオプジェクトに対して公開し、 API の互換性については、いくらか問題がある。そのは 内容を取得できるようにする程度であった。すなわち、本来は とんどは、 AWT の進化にともなうものだ。 AWT の実装 プライベートなインターフェイスを、すべてのパッケージに対 には、プラットホームによって異なった振舞いをするといっ して公開することになってしまう。 た問題があったが、これらへの対策がとられ、現在ではすべ 内部クラスにより、内容を取得するためのクラスを、必喫に てのプラットホームで共通のモデルが使えるようになった。 応してコンテナのプライベートなフィールドに直接アクセスす その結果、以前はチェックされなかった不正なコードを検 るプライベートな内部クラスとすることができる。 static か宣 出したり、イベントを矛盾なく処理するように、 API を部 言されない内部クラスは、自身を囲むオプジェクト ( 通常はそ 分的に変更しなければならなかった。この変更により、 1.0 れを生成するもの ) を暗黙裡に参照する。内容を取得するクラ 上で開発されたコードを 1.1 のプラットホーム上で実行す スは、基本的にコンテナ・オプジェクトの実装だから、これは る際に互換性にかかわる間題が生じた。 AWT のソースコ 侖理的である当に好ましい手法である。 ードの互換性に関する大半の問題を処理する sed スクリ 内部クラスを匿名化することもできる。これは、作藤殳階で プトが、 http://java・ sun ・ com/products/jdk/l.l/docs/ クラスを次のように茁妾宣言する。 guide/awt/updateAWT/ で公開されている。国際化作業の 一環として、 1.1 AWT ではすべての Unicode 文字列を表示 quitButton. setActionListener ( できるようになった。もちろん、表示するためのフォントが正 new ActionAdaptor ( ) { public VOid ActionPerformed(ActionEvent e) しくインストールされている必要がある。 Java. io パッケージの入出力ストリームは、国際化するう Sytem. exit(O) ; えでの問題点の 1 つであった。バイト I/O 向けに言 t され たこれらのストリームは、 Unicode 文字の下位 8 ピットだ けを用いたため、事実上 ISO-Latin 1 文字セットに限定さ れていた。そこで、新たに 16 ピット Unicode 文字を適正 このコードは、 JVM を終了させる [Quit] ボタンと結び に扱える Reader および Writer ストリームが追加された。 ついた ActionAdaptor という単屯なサプクラスを作成する。 そして、文字列を表示するときだけ、新しい PrintWriter ク 一三卩 93 UNIX MAGAZINE 1997.10

0 図 3 携帯舌を持つ人の身振りをテーマにした私乍品 ことが少ない。これは、私か老化したからではなく、本自 流し読みである。私自身、去も匠は、本を通して読むという けだが、そのもっとも分かりやすい身振りが、拾い読みや こうして、いまや、、読む " ことが参照することになるわ ミズムは想定されてはいなかった。 たように、ある種の、、秩序 " があるわけだが ) 的なダイナ のであって、カオス ( これにも、 llya prigogine か言っ の、、恣意性 " とは、あくまでも一定のコード内におけるも 「記号の恣意 (arbitraire du signe) を孑商したが、そ 可能になるということである。 Saussure は、たしかに 言い換えれは、これは、、、読む " という行為がもはや不 したかたちで、、差異の戲れ " に加わることはできない。 璧に、、恣意的 " なものと化す事態においては、もはや持続 かし、そのようなコードと差異の諸聞系か際限のない、完 のもとでおこなう、、差異の戲れ " に加わることである。し を構成する諸々のく意味するもの〉どうしかン -- ・定のコード れる " ものになり始めている。、、読む " という行為は、記号 読まれる " ものであるよりも、、、参照さ 字メディアは、 ある。現実間題として、いま、本、雑新聞といった活 前回、私が言及した、、参照 " も、このこととかかわりが ーション論は無効になりつつある。 手 " の幸福なーー材ヒといったことを想とするコミュニケ ものとなるのであり、すくなくとも、、、送り手 " と、、受け ションのなかてイ吏われてきた、、卍にが、いまや当り前の VRML 以則から気つ、かオ実際には日々のコミュニケー の 1 っとして、、、誤解するオリ " を挙げたことがあるが、 かって鶴見俊輔は、コミュニケーションの本質的な性格 できない。 も、そオ功坏当なコミュニケーションであるということは を変え、たとえば、、変態的 " な視点でそれを眺めるとして 私の設定した viewpoint を無視して、その姿態の、、視点 " 152 体がすでに、、参照 " のメディアに転身し始めているからな のだと考えたい。 英語でむと、、参照する " を意味する read 、 refer の語源は、ともに 14 1 世紀以前に遡る。 read は、もとも と、、解釈するケえる " といった能重加勺な未であった のに対して、 refer には、、イ頁する " とか、、譲り渡す " とい った半分受重加勺な意味があったという。つまり、 read に とって、その対象はぐ学えるべきもの〉であるが、 refer にとっては、逆に物・えられるべきもの〉なのである。実 際、オプジェクトは、ますそこにあり、我々がそれにアク セスしたときだけ、その、、身、糧彡 " を見せる。が、その、、射 影 " は、あくまでもオプジェクトの限られた、、プロフィー ル " にすぎない。 にがわ・てつお ) [ 赭文献 ] [ 1 ] Gilles Deleuze et Félix Guattari, Mille Plateau.T.• Capitalisme sc んた 0 〃ん r れ , Ed. du Minuit, 1980 ( 邦訳 : 野邦ーー尺『千のプラトー』、河出書房新社、 1994 [ 2 ] Félix Guattari, 月朝 0 ん 0 れ rno c 司 7 ℃ , lre éd. Ed. du Recherche, 1979 / éd. revue et augmentée, U. G. E. , 1980 ( 邦訳 : 本グ寸昌昭訳『分子革命』、証父た / : 出版 ) 、 1988 年 ) [ 3 第謹也「「世間」とは何か』、講談新書、 1995 年 UNIX MAGAZINE 1997.10