P前週号 | H日本語版ホーム | N次週号

TidBITS: Apple News for the Rest of Us  TidBITS#613/21-Jan-02

Classic, Carbon, それに Cocoa アプリケーション。その違いがわからないという向きには、Chris Pepper の Mac OS X プログラムの異なった生い立ちに関する解説記事がお役に立つのではなかろうか？Geoff Duncan は二つの古典とも言える Macintosh メールサーバに関しての新しい目での見直しについて語る。ニュースの部では、Apple 社の 3800万ドルの利益報告、Adobe InDesign 2.0 のリリース、AirPort ユーザと Mac OS X の多言語サポートに関する Apple からの数多いアップデートについてお知らせする。

記事：

Copyright 2005 TidBITS: Reuse governed by Creative Commons license
<http://www.tidbits.com/terms/> Contact: editors@tidbits.com>

本号の TidBITS のスポンサーは：

MailBITS/21-Jan-02

Apple 3800万ドル の利益計上 -- Apple Computer は 2002会計年度の第一四半期に、アナリストの予測通りの 3800万ドル の利益を計上した。製品のラインアップが古くなってきているにもかかわらず、この四半期で Apple は 746,000台 の Mac と 125,000台 の iPod を出荷した結果、売上高 13.8億ドル、粗利益率 30.7% の結果となった。Apple は米国周辺の Apple 直販店での売上高を公表してはいないが、12月だけでも 80万人を越える来客があったと発表している。米国外での販売が Apple の売上の 48% を占めている。また、Apple によると新規設計の G4 iMac の受注は予想以上で、この第二四半期の売上も増大すると予測している - これは今の低迷する経済の中にいるコンピュータメーカーとしては大変めずらしいことである。[GD]（カメ）

<http://www.apple.com/pr/library/2002/jan/16results.html>
<http://db.tidbits.com/getbits.acgi?tbart=06682>(日本語)Macworld Expo SF 2002 基調講演 : 喝采? それともハッタリ?

Apple 社 AirPort(AirMac), Mac OS X Language をアップデート -- Apple は先週末 Software Update を通じての数多くのアップデートをリリースした。AirPort Driver Update 2.0.1 は Mac OS 9 及び Mac OS X 両方の版があり AirPort Card 用のアップデートされたドライバが含まれており、安定性とパスワードで保護された Computer-to-Computer ネットワークをつなぐ時パスワードを要求する警告を的確にだすことが改善されている。その他には、オリジナルの AirPort Base Station（グラファイト色; 新しい AirPort Base Station は新型 iBook と同じ白い色をしておりこのファームウェアのアップデートは不要）用の新しいファームウェアが提供されている。オリジナルの AirPort Base Station 用のアップデートで改善されたのは PPPoE サポートである；アップデートをダウンロードした後、AirPort Admin Utility を起動して Configure をクリックすればアップデートプロセスが始る。

<http://www.apple.com/airport/>

週末にかけて Apple は Mac OS X の多言語対応に対するアップデートもリリースした。対象は Brazilian Portuguese, Simplified Chinese, Traditional Chinese, Danish, Finnish, Korean, Norwegian, それに Swedish である。多くの人がこれらすべての言語を必要とする事はないとは思うが、すでにインストール済の Mac OS X には古いバージョンが含まれているので、ひょんなことから使用言語を変更したいという稀な事態が来ても困らないようにこれをダウンロードして最新版にしておくのは悪くないのではなかろうか。勿論反対に、Software Update で不必要な言語を選択し File メニューから Make Inactive を選ぶことで、今後の Software Update のリストが混雑するのを避ける選択するのも手ではある。[ACE]（カメ)

Adobe InDesign 2.0 出荷 -- Adobe 社は、同社の次世代型ページレイアウトアプリケーションを大幅にアップデートした Adobe InDesign 2.0 の出荷を始めた。InDesign 2.0 では、オブジェクトの透明効果が編集可能となっており、例えば境界ぼかしやドロップシャドウの中での透明度を維持したままで Photoshop や Illustrator のファイルをインポートすることが出来る。またこの新版には、表の作成やインポートのためのツールの強化、OpenType フォントのサポート強化、他の Adobe 製品との連携強化が含まれている。そんな中でも最も意味のあることは、InDesign 2.0 が Mac OS X のネイティブサポートをしている事であろう。これは競争相手の QuarkXPress がすぐには対応できそうもないことだからである。最後に、Adobe 社はこのリリースで 2001年の最後にはまり込んだ難題の法的苦難から自らを解放することになる；同社は地裁判事から C-Index と呼ばれる InDesign のコンポーネントに関しての Trio Systems LLC との特許論争にからんで InDesign 1.5 の販売を差止める判断を受けたからである。この後、その内容は公表されていないがすぐに和解が成立している；InDesign 2.0 は C-Index コードを含んでいない。InDesign 2.0 の小売価格は $700 である。InDesign の旧バージョン所有者に対するアップグレードは $100 で、PageMaker か PageMaker Plus の所有者に対しては $300 となっている。[JLC]（カメ）

<http://www.adobe.com/products/indesign/>
<http://www.triosystems.com/ci2/>

Mac メールサーバふたつが里帰り

文：Geoff Duncan <geoff@tidbits.com>
訳：倉石毅雄 <takeo.kuraishi@attglobal.net>

Mac を使用してインターネットメールサービスを提供している人達の間では、 Windows や Unix のサーバ機種に比べ、Mac OS でのメールサーバの選択肢が決して多くないということは一般的知識である。何年もの間、Mac ユーザには片手で数えるほどのメールサーバの選択肢しかなく、それらも Mac OS X によって存続が危ぶまれている。Unix を土台にしているから、Mac OS X システムはハイエンドの Unix ベースのメールサーバを走らせることが出来る。それらは頑丈ではあるが、設定や管理が難しいことで有名だ。

しかし、昔からの Macintosh のメールサーバ製品が復活の兆しを見せている。これには、Macintosh の使い易さを手放したくない忠実なユーザ層も一役買っているのかもしれない。2000 年の MCF Software による、古くからあるメーリングリストサーバの ListSTAR 買収に始まり、最近は LetterRip と EIMS の二つの定評のある Mac メールサーバがこの流れに加わった。

<http://www.mcfsoftware.com/>
<http://db.tidbits.com/getbits.acgi?tbart=06158>(日本語)ListSTAR、4D 社から MCF Software 社へ移管

LetterRip -- LetterRip Pro は Emailer をも開発した Fog City Software で開発された人気あるメーリングリストサーバだ。LetterRip はその安定性、性能、そして使い易さが売り物だ。もっと古く、複雑な ListSTAR ほど柔軟ではないものの、LetterRip はほとんどのメーリングリストに十分であり、熱狂的なユーザ集団に後押しされている。（実は TidBITS は両方の製品を使用している：TidBITS Talk、翻訳チーム、その他のプライベートなメーリングリストなどは LetterRip が管理しており、TidBITS の配布やもっと複雑なメールの処理には ListSTAR を使用している。）

<http://db.tidbits.com/getbits.acgi?tbart=05328>(日本語)LetterRip Pro を使えばあなたもプロに

LetterRip Pro は 1999 年にリリースされ、それ以降大きな更新はされていない。そのため、この製品は消滅寸前なのだろうと噂されていた（もっとも、Fog City のサポートは迅速だし、Mac OS の新しいバージョンで出てきた問題点を解決するのも早かったが）。しかし、流れは変わったようだ。2001年 1月 2日付けで、LetterRip Pro は、それを Mac OS X に移植して新しい機能を提供するという目的で設立された LetterRip Software に買収された。LetterRip の開発は、Fog City で LetterRip の元の開発メンバーの一人だった Jud Spencer が中心となっている。Jud はまた、いまだ根強い人気がある Emailer や、Microsoft の Outlook Express や Entourage の開発メンバーの一人でもあった。LetterRip メーリングリストは、将来のバージョンにどんな機能がもっとも有用であるかという議論で盛り上がっている。LetterRip Pro ユーザで、意見があるなら、今がチャンスだ。

<http://www.letterrip.com/>

EIMS -- EIMS にとっては長く曲折に満ちた道のりだった。このプログラムは、インターネットが一般に知られるようになるはるか前に、ニュージーランドの Glenn Anderson によって Macintosh のために書かれた MailShare という簡単な SMTP と POP メールサーバとして誕生した。インターネットサーバ市場に参入しようとしていた Apple は、1995 年に（Glenn ごと）MailShare を手に入れ、 Apple Internet Mail Server（AIMS）と名前を変えた。（AISS という略語を覚えている人はいるだろうか？）その後、Apple がやっぱりインターネットサーバには手を出したくもないと決めたので、Qualcomm が AIMS (と Glenn) を 1997 年に救い上げ、Eudora Internet Mail Server（EIMS）と命名し直した。Qualcomm では、Glenn のもとで EIMS は二つの大きなアップグレードを経て、IMAP、DNS ブラックリスト、遠隔管理、そしてその他の多くの機能を追加した。EIMS は今だ頑丈で高性能なサーバだ。

<http://db.tidbits.com/getbits.acgi?tbart=01532>

2001年 12月 21日付で、EIMS は再び、長距離便で家路に就いた。Glenn Anderson は Qualcomm から EIMS のライセンスを取り戻し、EIMS 3.1 をリリースした。Glenn は同時に、Mac OS X 用に EIMS Admin アプリケーションを作っている（アルファ版が現在入手可能だ）。しかし、Mac OS X 版の EIMS サーバの予定はまだ不明だ。完全版の機能全てを必要としない人のために、Glenn は EIMS の低価格の機能限定版をも考えている。

<http://www.eudora.co.nz/>

EIMS 3.1 では、多くの性能改善、Apple Event サポートと性能の向上、Outlook と Outlook Express のための NTLM 認証、POP3 のための CRAM-MD5 認証、LDAP 認証、 配達不可メッセージ中の配送状況通知情報、そして順番待ちの遅れや送受信したメッセージ総数などの統計情報などが加わった。EIMS 3.1 の新規購入は $400 だが、3.0.x からのアップグレードは $60 で、2.x からは $150 だけだ。

お帰りなさい -- Mac OS X が Mac を使用したインターネットサービスでの新境地を拓くのと同時に、昔からの Mac デベロッパーがこれらの定評ある長寿製品に新しく息を吹き込んでくれるのは嬉しいことだ。これは、精巧でかつ使いやすい製品が当たり前と思われる Mac の世界でしか起きないような事だ。Unix で鍛えられた者はメールやメーリングリストには Unix 製品を使う方を好むかも知れない。しかし、そうでない我々は、なぜ Mac ソフトが他のソフトとは一線を画いているかを理解する人達によって設計され開発された製品を常に - そしてこれからも - 支持してきた。

Mac OS X： 異種のプログラムが同居−その１

文：Chris Pepper <pepper@reppep.com>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
訳： 溝畑 考史 <mizo-tid@grf-design.com>

Apple の新しいオペレーティングシステムについて議論をすればするほど、この Mac OS X がそれ自身いくら良いものであったとしても、Apple の外部で作られるアプリケーションたちの存在が無ければ決して成功したとは言えない、という強い確信が湧いてくる。だからこそ Apple は多くの努力を傾けて開発者たちに働きかけ、この新しいオペレーティングシステムをフルに活用し、さらには Mac OS X の上のみで動作するようなソフトウェアを作る（結果としてそれがユーザーを Mac OS X に移行させる力にもなる）ようにと促し、圧力をかけようとしているのだ。しかし、残念ながら Mac OS X にしても Carbon（同じプログラムが Mac OS 8.6/9.x でも Mac OS X でも走ることができるようにするためのテクノロジー）にしても、まだ比較的登場してから日の浅いものなので、開発者たちは Apple からの Carbon を勧める圧力と、Carbon の実態としての不完全さとの板ばさみになっている、というのが実情なのだ。Mac OS X 10.1.2 の登場によって成熟度がかなり増したのは確かだが、それでもやはり、Macintosh の登場以前の Apple Lisa コンピュータの時代以来 20 年余にわたって培われてきた Classic Mac OS の洗練さにはとうてい太刀打ちできるものではない。

<http://www.apple.com/macosx/>
<http://guide.apple.com/macosx/>

Mac OS X はいくつかの既存の製品を一つの新しいモダンなオペレーティングシステムとして結び付けたものであって、その元となった製品たちは、それぞれ固有の個性とユーザー・コミュニティとを持ち込んで来ている。さらにおもしろいことには、Apple が Mac OS X の中に織り込んだもののいくつかは歴史的に互いにまったく相異なる方向に進んできたものだった。例えば Classic Mac OS が技術指向でないユーザーを念頭に作られているのに対して、Unix はプログラマーを念頭に作られている。これらから生まれた Mac OS X は、驚くほどうまくブレンドされた成功作と言えるのだが、それでもやはりこの異種混血という本質は時々意外なところにその正体を現わすのだ。これら異種の構成要素たちは、それぞれ独自のインターフェイス、指向性、独自のアプリケーションを持っているので、それぞれのプログラムの独自の伝統といったものをよく理解せずに Mac OS X の全貌を掴むのは不可能というものだろう。今回の「その１」では、たいていの Mac OS ユーザーならばある程度なじみがあるはずの、アプリケーションの種類を３つ、“Classic”“Carbon”“Cocoa”、について解説してみたい。Mac OS 総体の中における位置付けとしての、それぞれの利点と弱点とを探ってみよう。次回の「その２」では、Mac OS X における Java のサポートの利点を説明し、さらに純粋に Unix のために書かれたアプリケーションについて、これが実は Apple の新しいオペレーティングシステムの核心となるべきものだ、ということについて述べたいと思う。

<http://developer.apple.com/macosx/architecture/>

API の花盛り -- 現在の Mac OS X アプリケーションの種類を決定づける特質は、そのアプリケーションが利用する API（Application Programming Interfaces）のセットによって決まる。これは、アプリケーションがオペレーティングシステムに対して発することのできる要求命令の集まりを規定したものだ。例えば「今何時？」とか、「このパラグラフを Palatino 12 フォントでこのウィンドウに描け」とか、「この URL をヘルプビューアで開け」とかいった命令だ。余分な動作を省略するために、プログラムはできる限り API を利用しようとする。その結果、例えばほとんどのプログラムは直接フォントを扱う必要がなくなる。フォントメニューを構築したり、テキストを特定のフォントで表示したり、といった作業は OS にやってもらうわけだ。Mac OS X においてはその長くて複雑な歴史の結果として、プログラマーはいくつかの異なった APIセットの中から好きなものを選ぶことができる。これらの API セットはそれぞれに特徴を持っていて、その API を使用するプログラムには自然とそれらの特徴が現われることになる。

Mac OS X は、まず Apple の Classic API に基づくアプリケーションを走らせることができる。これらのアプリケーションは Mac OS 9（やそれ以前）でも動作し、その API は以前は Mac Toolbox と呼ばれていた。Mac OS X はまた Carbon API もサポートしている。Carbon API は Mac Toolbox の部分集合であって、Mac OS 9 との互換性を保ちつつも、Mac OS 9 とは非互換な変更を加えることによって Mac OS X における重要な利点を実現させている。Carbon によって実現された利点の主なものとしては、プリエンプティブなマルチタスク、より高度な仮想メモリ、アプリケーションのクラッシュからの OS の保護、などという Mac OS X の特性が挙げられる。これらの利点は Carbon アプリケーションを Mac OS 9 で走らせた場合には実現されない。さらに、Mac OS X には NeXT-由来の Cocoa API もある。実際、今日の Cocoa アプリケーションの多くは以前から NeXTstep の下で存在していたものたちだ。この NeXTstep こそ、Steve Jobs が以前持っていた会社、NeXT によって開発されたオペレーティングシステムなのだ。

以上３つの API セットは、いずれも Apple 独自（独占）のものだが、Mac OS X はそれ以外にも、さらにあと２つの重要な公開 API セットもサポートしている。（これら２つについては、この記事の第２部で解説する予定だ。）まず、Mac OS X は Java API をサポートしている。これは Sun 社によってデザインされた API で、Java プログラミング言語を使って多種のオペレーティングシステムの下で動作するプログラムの作成を可能にするために作られたものだ。それから、Unix API は、Apple のオープンソースの Unix オペレーティングシステムの基礎となる Darwin を通じてサポートされている。この Unix API レイヤーは BSD Unix に基づいており、Mac OS X におけるパワフルな Apache ウェブサーバーもこの Unix API レイヤーによるものだ。以上のような API の多彩さこそが Mac OS X の最大の特徴で、１つのオペレーティングシステムとしては誰も信じられないほど多種多様なアプリケーションが Mac OS X の下で動作が可能となっている。しかし一方、多種のタイプのプログラムが同時に動作するということは、それらを使うユーザーにとっては混乱のもととなる、ということも否めない。

<http://java.sun.com/>
<http://www.apple.com/macosx/technologies/darwin.html>
<http://httpd.apache.org/>

Classic -- Mac OS X の下で動作するプログラムのうち、（少なくとも現時点で）一番なじみのあるものは、Classic プログラムだろう。これは、主に Mac OS のバージョン 7 から 9 までのために書かれたプログラムで、Mac OS X の下でも基本的に Mac OS 9 の下でと全く同じに動作する。この動作を実現させるために、Mac OS 9 そのものが Mac OS X の下での不可視プログラムとして動作している。（いみじくも Classic という名前のプログラムだ。）この、Mac OS X の下での Classic レイヤーは、ほとんどのプログラムが Mac OS 9 の下でと全く同じ方法で Mac OS X の下でも動作できる環境を提供する。ただし、ハードウェアを直接にコントロールするようなタイプのプログラムは例外で、例えば CD レコーダーのようなものは Mac OS X の下ではそういう機器を管理するドライバーが新しく非互換なものに変わっているので動作できない。

Classic によって提供された広範な互換性こそが Mac OS X の成功の鍵となったことは言うまでもない。既存の多くの Classic プログラムを毎日 Mac OS X で使い続けられることによって、人々はプログラムが更新されるのを何年も待つようなこともなしに、これまで通りのプログラムをそのまま使って仕事をこなしてゆけるからだ。Microsoft Office 2001 や Eudora 5.1 が、重要な Classic プログラムの典型的な実例と言えるだろう。Office アプリケーションのおかげで人々は Mac OS X でも Word で文章を書き、Office 書類を共有し、会計計算をいつも通りにこなすことができて、Microsoft が Office X の Carbon 化バージョンを 2001 年の 11 月にリリースしてくれるのを慌てずに待つことができるわけだ。また、Eudora の Classic バージョンも依然として Mac OS X で広く使われており、Qualcomm もゆっくりと Eudora の Carbon ベータ版に取り組んでゆけるわけだ。（最近のベータ版には非常な進歩が見られる。）

<http://www.microsoft.com/mac/office/>
<http://www.microsoft.com/mac/officex/>
<http://www.eudora.com/betas/>

Classic API は本来 Mac OS 9 に基づいているので、Classic プログラムは Mac OS X の新機能をフルに利用することはできない。加えて、Classic は Mac OS 9 のフルコピーを Mac OS X の内部に走らせて動作するので、はなはだしい重複が必然的に起こっている。これらの重複のうちのいくつかはうまく処理されているが、いくつかは良くない結果を引き起こしている。例えば、ファイルサーバーへの接続は Classic のセレクタを使っても、Carbon の Finder を使っても、いずれでもできる。どちらで接続した場合にも、ファイルサーバーは Classic と Carbon 双方のプログラムで利用可能だ。しかし、ファイルへのナビゲーションの方法によって、現われる場所が違ってしまう。Carbon Finder はファイルサーバーをデスクトップの表示するか、またはコンピュータのトップレベルのフォルダとして表示する。旧タイプの開く / 保存ダイアログやナビゲーションサービスでは、トップレベルに現われるが、コンピュータのコンテナは表示されない。Terminal やその他の Unix-ベースのプログラムでは、トップレベルの Volumes フォルダに現われる。

Classic プログラムを動作させるためには、まず Mac OS 9 を「起動」させねばならない。つまり、最初に Classic プログラムを起動させる際には非常に長い時間がかかる、ということだ。こうして起動された Classic 環境はログアウトまたは再起動するまでは走り続けているが、もしも Classic がクラッシュした場合には Classic プログラムはすべて共倒れとなる。（新しいメモリ保護モデルの恩恵を受けることができるのは Carbon と Cocoa のプログラムのみだ。）さらに、Classic/Carbon アプリケーションと Cocoa アプリケーションとは完全に別々のクリップボードを使用しているので、両者のクリップボードを同期させるためにいつも短時間ながら遅れが生ずる。つまり、Classic プログラムでコピーをしてから Cocoa プログラムに移ってペーストすると（あるいは逆の場合でも）思いもかけないものがペーストされてしまうこともあるのだ。

Carbon -- Mac OS X 下で稼働する Carbon 化アプリケーションはより興味深い。なぜならそれらのアプリケーションは、 Cocoa 環境用に完全に書き直すよりも少ない努力によって、Mac OS X で導入された改善点を自動的に利用するからだ。改善されたメモリ管理、ライヴウィンドウドラッグといった、いくつかの大きな変更点は、暗黙かつ自動的に全ての Carbon アプリケーションに適用される。（Mac OS X のそれ以外の変更点を利用するには、Carbon に移植されたどんなアプリケーションにおいても明示的なサポートが必要となる。）付け加えると、Apple は現在、本質的な OS 開発リソースの全てをMac OS Xに注いでいる。したがって Apple の現在進行中の開発作業の恩恵は　Mac OS 9 から（現在は Mac OS X とより良く協調することを主眼に改訂されている。）新しいプラットフォームに移行している。Mac OS X は急速により良くなっていて、そしてそれらの改善点は Carbon と Cocoa アプリケーションに集中している。

<http://developer.apple.com/carbon/>

一旦デベロッパー達が彼らの Classic アプリケーションを Carbon 化して新しい環境になじめば、新しい多くの機能を盛り込む代わりに現存のアプリケーションを Carbon に移行させるだけ、という現状を脱して、開発・改善の普通のプロセスが再び見られるようになるだろう。デベロッパー達は Classic アプリケーションに関して取り組むのを止め、Carbon や Mac OS X に関心をシフトしはじめている。この移行が発生するスピードは Apple にとって重要である。もしそれが遅すぎれば、人々は“業務”に Mac OS 9 を使い続け、Mac OS X に関してはオモチャ程度にしか思わないだろう。要となるデベロッパー達が段々と Mac OS 9 に関する開発を止めるにつれて（例えば Microsoft はもう止めた）アップグレードへの圧力は段々と強くなるだろう。

Classic アプリケーションと Carbon アプリケーションとはウィンドウインターフェイスの違いによって容易に区別できる。Classic アプリケーションは古い 2D のプラチナアピアランスを使っている（四角形ウィンドウ、グレイの縁、ズームボックスは右上）が、一方の Carbon（と Cocoa）アプリケーションはアクアインターフェイスを使っている。それは丸みを帯びたエッジに、影がついて、3D スタイルのボタンに、色が付いた閉じる・最小化・ズームの機能を持つボタンが左上にある。

Mac OS X の改善点は Mac 用アプリケーションに新しい可能性を開いた。現状では Carbon アプリケーションの多くは Classic アプリケーションのただのカワイイ版だが、Apple はそのことだけに注意を引いているのではない。Carbon での機能完成を成し遂げた後、デベロッパー達は Mac OS X に固有の機能を彼らのアプリケーションに盛り込みはじめるだろう。例えば Interarchy 4.1 と BBEdit 6.1 に関して言えば、両者ともに現存の Classic バージョンとほぼ同等の機能を持つ Carbon バージョンを達成している。そして次作となる Interarchy 5 では、Mac OS X のおかげで、FTP 転送に OpenSSH 暗号を使用しているし、BBEdit 6.5 では、例えば Unix シェルワークシートウィンドウや、コマンドラインから BBEdit を操作できるというように、外部プログラミングツールとのより良い統合をはかっている。それらは Mac OS X が非常に豊富に新しい API を持つため、成長のための凄まじいほどの可能性を提供しているからなのだ。

<http://www.interarchy.com/>
<http://www.barebones.com/products/bbedit.html>
<http://www.openssh.org/>

アプリケーションを移行するための差し迫った課題の先を眺めてみよう。マウスクリック、キー入力、ウィンドウドラッグ、等々といったシステムがイベントを扱う基本的な方法の変化に表されるように、Apple は Carbon を新しいアプリケーションを開発するための最高のプラットフォームにしようと企てている。Classic アプリケーションではユーザが何かするのを待つというタイトなループの中で稼働している。そうしながらも、Classic アプリケーションはプロセッササイクルを他の（Classic）アプリケーションに任意に分け与えている。もし Classic アプリケーションが何にもしていなかったとしても、イベントを待つためにプロセッササイクルを消費し続けているのだ。

対照的に Mac OS X の Carbon アプリケーションはイベントを扱うために Carbon イベントと呼ばれる、別のアプローチを利用することが出来る（Cocoa アプリケーションと同じ方法）。Carbon イベントでは、アプリケーションが反応すべきイベントの種類と、それらのイベントにどのように反応するかを、OS を通じて登録する。そのようなあるイベントが起こった際、OS は正しいアプリケーションの反応を引き起こすが、何も重要なことが起こらないと、アプリケーションは 全く プロセッサタイムを消費しない。このアイデアは、プログラマーが興味を持つ特に重要な事柄のみを扱えばいいので、アプリケーションをよりシンプルにする。そしてアプリケーションが何かするときのみ、プロセッササイクルを借りるので、システム全体を速くするのだ。

<http://developer.apple.com/techpubs/macosx/Essentials/Performance/Carbon/Carbon_and__OS_X_Events.html>

Cocoa -- Steve Jobs は Apple 社を去った後 NeXT 社を創設した。NeXT は Apple のプロトタイプに似たコンピュータを最先端のハードウェアを使って実現したが、そのテクノロジーの多くは Mac と同じもの（例えば Motorola プロセッサ、PostScript、その他）を使っていた。この最先端のハードウェアに適合させるために NeXT は NeXTstep ソフトウェアを開発したが、これは基本的に３つのものから成っていた。Unix-ベースのオペレーティングシステム、Adobe の Display PostScript に基づいたウィンドウイングシステム、そして、グラフィカルなアプリケーションを素早く作れることを目指したプログラミング API だ。この API はその後も進化を続け、NeXT がハードウェアビジネスから撤退した時には OpenStep となり、そして Apple が NeXT を買収した時に Cocoa となったのだ。

つまり Cocoa は Mac OS X に統合されるよりもはるか以前からすでに成熟していた。これは、Mac OS X の開発の初期の段階で初めて Apple がデザインし、書き始められた Carbon とは対照的だ。この理由で、NeXT 開発者たち、例えば The Omni Group や Stone Design などの作った Cocoa アプリケーションは、Carbon アプリケーションに比べて当初はかなりの有利さを持っていたと言える。その後 Apple が Mac OS X 10.0 から 10.1 と、Carbon 環境にも肉付けを加えていくにつれて、Carbon も、そのアプリケーションも、Cocoa とほぼ対等と言えるものに成長してきた。もちろん、両者にはそれぞれの利点と弱点とがある。Cocoa アプリケーションには、プログラマーの側から見ればはるかに少ない労力で作ることができるという利点がある。これは、Cocoa があらゆることをすでに用意してくれているからだ。他方、Carbon アプリケーションを書く作業は、 Macintosh 開発者たちにとっては以前からずっとお馴染みの作業とも言える。その上、Macintosh 開発者たちにとってはできて当り前と思えることなのに Carbon でしかできない、というものも少なからずあるのだ。しかし、Apple が今後両者ともに進化させ続けてくれるにつれて、双方の環境で書かれたプログラムの差異は次第に減ってゆくだろう。

<http://www.omnigroup.com/>
<http://www.stone.com/>

Carbon アプリケーションと Cocoa アプリケーションとを見分けるのは、双方ともに同じ Aqua アピアランスを使っていることもあってなかなか難しいが、いくつか見分けるコツはある。そのアプリケーションが比較的サイズが小さくて、（Mail と同じような）引出しを使っており、フォントの選択にフォントパネルを備えているなら、たぶんそれは Cocoa アプリケーションだ。また、ちょっとしたことだが現時点でアプリケーションが Carbon か Cocoa かによる違いとしては、開く / 保存のダイアログ内でのユーザーによるナビゲーションの方法の違いがある。（この不統一性についての詳細は、TidBITS-jp-601の記事“Appleの隠れた汚点”を参照されたい。）Apple は（賢明なことに）こうした不統一性をなくそうと努力している。長期的に見れば、アプリケーションの内部構造が NeXT 伝統のオブジェクト指向のものであるか Classic Mac OS の伝統に根差したものであるかという違いは、ユーザーにとってはどちらでも良いことだろう。もちろん、Cocoa アプリケーション用のコードの多くがすでに Mac OS X に内蔵されているという事実によって、 Cocoa アプリケーションの方が Carbon アプリケーションよりもサイズがかなり小さくなるということは変わらないだろうが。

<http://db.tidbits.com/getbits.acgi?tbart=06594>(日本語)Appleの隠れた汚点

お父さんの Mac とは別モノ -- この記事を書いている現時点では、依然として Classic が Mac OS X の本質的部分を占めている。それは、Carbon 化もされていないし Cocoa 版も無いような Classic アプリケーションが多数あるからだ。今後、開発者たちが Carbon ないし Cocoa のプログラムを発表していくにつれて、Classic は次第に Mac OS の歴史の遺物と化していくだろう。現在すでに、Mac OS 用のソフトウェアのメジャーなリリースの多くは Carbon アプリケーションとなっている。Classic 専用の QuarkXPress 5.0 くらいが大きな例外と言えるだろう。現状では、これまで既存のコードベースの大きさと Cocoa への馴染みの薄さから、Cocoa アプリケーションはまだ少数派だ。けれども NeXTstep/Cocoa 開発者たちにとっては、今こそ彼らのプログラミング環境の利点を実証し、既存の Mac 開発者たちを Cocoa へと口説き寄せる絶好のチャンスだ。新たに Carbon アプリケーションを書き始めるのに比べてはるかに少ない労力で、Mac OS X の利点のすべてを利用できるアプリケーションが作れるのだから。

Mac OS X でのプログラムは Classic、Carbon、Cocoa だけには止まらない。Unix や Java のプログラムもネイティブにサポートされている。これらの環境での Macintosh 開発は今始まったばかりの段階だ。しかし、これまで Mac には馴染みの薄かった多くの開発者たちが Mac OS X の可能性に目を向けるようになるにつれて、この Apple の「両方良いとこ取り」のオペレーティングシステムは、ますます世界の注目を獲得するようになってゆくだろう。この記事の続編Mac OS X：異種のプログラムが同居−その 2では、こうした Unix や Java の開発環境について見てゆきたいと思う。

［Chris Pepper はニューヨーク在住の Unix システム管理者だ。彼の仕事上の Unix システムのための管理ワークステーションとして Mac OS X がこんなにも便利だという事実を、彼は嬉しく思うと同時にかなりの驚きの念をもって迎えている。Chris はまた、Interarchy や Apache Group など、いろいろなソフトウェア関係の著作の仕事もしている。］

<http://www.reppep.com/~pepper/>

tb_badge_trans-jp2

非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017

Valid XHTML 1.0! , Let iCab smile , Another HTML-lint gateway 日本語版最終更新：2005年 12月 26日 月曜日, S. HOSOKAWA

P前週号 | H日本語版ホーム | N次週号