Macintosh Developer Online (MDOnline)

2001年4月6日発行号 - Navigation Serviceと拡張子

特に記事にはしませんが、MicrosoftはOffice XPを2001年6月までに出荷します。それには、SharePoint Team ServicesというWebアプリケーションが含まれています。Windows 2000でないと稼動しませんが、Professionalでも使えます。Webコミュニティ向けのソフトで、グループウエア的に使うことも可能だと言えるでしょう。カスタマイズがいろいろできるのもいいところです。さっそく社内向けのサイトをこれで作って運用するなどのチェックをしています。以前にロータスのQuickPlaceを紹介しましたけど、ある意味では似ています。QuickPlaceって実は販売店では売っていなくてロータスのパートナーから購入しないといけないなど、ちょっと手軽な製品ではないのが難点なんです。しかしながら、SharePointはOfficeのコンポーネントですから、おそらくそれなりにきちんとサポート情報なんかも出すでしょう。仕事の合間に、ちょっとずついろいろカスタマイズして試しているところですが、Internet Explorerであれば、Mac OSのものもでも、Mac OS Xのものでもいちおう使えるみたいです。一部の機能はダメっぽいですけど、通常のブラウズには問題ないでしょう。会社の業務で使うシステムでは、安価で安直で効果あるというものを常に探し求めていますけど、その意味ではかなりいい線いっていますね。で、デフォルトではMSDEを使うのですが、アクセス頻度が上がると、SQL Server 2000を買うようになるという構造になっています。いずれにしても、データベースやアプリケーションサーバはもはや単体での競争は終わっているのかもしれません。プラスアルファを求めるとすると、1つはこうしたソリューションの提供です。SharePointは、Microsoft社製品への集約（囲い込みとも言えなくもないけど）を、Webアプリケーションから攻める製品と言えるでしょう。
（新居雅行 msyk@mdonline.jp）

小池邦人のプログラミング日記》2001/4/6＜Navigation Serviceと拡張子＞

今回は、Carbonアプリケーションの開発現場から見た「Mac OS X v10.0」の問題点を指摘してみたいと思います。NibベースのCarbonアプリの解説は、ProjectBuilderのパブリックβ版からの変更点を見極めてから再開する予定です。ご了承ください。

私が利用しているMetrowerks CodeWarriorは、すでにCarbon化されていますので、Mac OS X上でNativeアプリとして起動できます。ただし、パブリックβ版以前のMac OS Xをリファレンスに開発されていることから、製品版に対する最適化がなされておらず、エディターでの文字入力が非常に遅いといった弊害も目立ちます。風の便りに聞くところによると、Mac OS X正式版をレファレンスに最適化されたCodeWarrior IDE （もしくはアップデータが）が、5月のWWDCごろまでには配布されるのではないかという噂もあります。片やProjectBuilderの方は、β版と比較すれば随分と良くなったのですが、いかんせんコンパイルスピードが遅いのがネックです。現状、Mach-OベースのCarbonアプリを開発するのなら、とりあえずCodeWarrior環境できっちりとソースコードを開発し、それをProjectBuilderに渡して再度メイクするといった手段が一番かもしれません。

さっそく自作のCarbonアプリをMac OS X上で動かしてみたところ、いくつかの問題点に遭遇しました。CarbonLibは未だ発展途上なので、バグを含めて多くの不都合があるのは認識していますが、Mac OS X 環境自身に原因が起因する問題点も多いようです。自作アプリでファイルの保存をしようとしたところ、先んじて入力されているファイル名を（例えば「名称未定義」など）deleteキーで消さないとキー入力できない現象に遭遇しました。

　

それを一度削除してしまえば、その後はちゃんと日本語入力ができます。加えて、ファイル保存が正常に終了しない場合もあるようです。Carbonアプリでファイル保存を行うには、Navigation ServiceのNavPutFile()を呼びます。ソースコードレベルで調べてみると、ファイル名を入力したにもかかわらず、それがFSSpec構造体のnameメンバー（ファイル名）に反映されず、NULLストリングス（ゼロ）が返えって来ているのが原因でした。NavPutFile()からファイル名が得られないわけですからファイル保存は正常に行えません（涙）。これは自作アプリだけの現象でなく、AppleWorks 6でも同様に起こりました。AppleWorks 6でこの現象が起こると、アプリケーション自体が異常終了してしまいます（当然だと思う）。

さらに詳しく調べてみると、NavPutFile()のダイアログが表示された時点で英語スクリプト（英語入力モード）が選択されていると、日本語ファイル名を入力しても、それがFSSpecに反映されないことが分かりました。よって日本語スクリプトに切り替えてから入力すれば、問題なく日本語ファイル名は入ります。しかし、ダイアログを抜ける前に英語スクリプトに戻してしまうと、やはりFSSpecにはファイル名が代入されていません。とりあえず、NavPutFile()を呼ぶ前にKeyScript( smKeySysScript )を実行し、強制的に日本語スクリプトに切り替えておけば事故の確率は下がります。とは言っても、ユーザがダイアログを抜ける前に英語スクリプトに切り替えてしまえば元の木阿弥です。多分Navigation Serviceのバグでしょうが、改善されるまで待てませんので、ファイル名が入っていなかったら再入力を促す処理を追加することにしました。

次は、ファイルオープン時に使うNavGetFile()についての問題点です。昔々、ファイル選択ダイアログでプレビュー表示をさせたい場合には、StandardGetFilePreview()というAPI（CarbonLibでは利用できない）を使っていました。このAPIは、選択ファイルがQuickTimeでインポートできる画像、映像、サウンドなら、特別な処理をしなくても自動でプレビューを表示してくれました。ところが、Carbon環境で使用が義務付けられているNavGetFile()は、画像ファイルにプレビューリソース（’pnot’リソース）とサムネイルデータが付加されていないとプレビュー表示ができません。Navigation Serviceのドキュメントにはちゃんと「できる」と記載されているにもかかわらずです。ただし、この制限はMac OS 9上だけであり、Mac OS XのNavGetFile()では、ちゃんとQuickTimeインポートにによるプレビュー表示が復活しています。

　

「やれ嬉や！」と喜んだのもつかの間..。NavGetFile()のダイアログで画像ファイル名をダブルクリックしてもプレビュー表示が優先され、ファイル選択が認識されない現象が起こります。この現象は、プレビュー表示に時間がかかる場合（大サイズの画像ファイル）に起こるようです。ユーザとしては、プレビューなど見る必要がなく、ダブルクリックで即座にファイルをオープンしたい時があります。現状では、プレビュー表示がファイル選択の操作性を悪くしてしまうケースがあるようです。こちらはソースレベルで解消できる問題ではないので、クリックによるプレビュー表示よりもダブルクリックによるファイル選択を優先するように、Appleに変更してもらうしかありません。また、NavGetFile()が表示するリストに、同じフォルダが二つ表示されるという問題点も見つけました。以下の例では「Users」フォルダが二つ存在してしまっています。

　

Navigation Serviceは、ファイルオープンや保存と言った非常に重要な操作に関わるモジュールですので、Appleは最優先でバグフィックスを行うべきでしょう。
（続く）

関連リンク：オッティモ
カテゴリ：ユーザインタフェース, 小池邦人のプログラミング日記

小池邦人のプログラミング日記》2001/4/6＜Navigation Serviceと拡張子＞〜続き

続いて、ファイル名の最後に付けられる「拡張子」の問題点についてです。Mac OS Xでも、保存ファイルにはファイルタイプとクリエータを付加することができます。そういう意味では、Mac OS 9環境からの大きな変更はありません。しかし、Mac OS Xに付属している「Grab」などのCocoaアプリケーションは、ファイルタイプやクリエータを持たないTIFFファイルを保存してしまいます。またマウントされたデジカメのスマートメディアやコンパクトフラッシュのJPEGファイルなども、ファイルタイプを持たないファイルとして認識されているようです。Mac OS 9では、File Exchangeがファイル名の拡張子を判別し、自動でファイルタイプを割り振ってくれていました。ところが、Mac OS Xではその仕組みがまだ存在しないわけです。これはバグなのか？未実装なのか？仕様なのか？当方では判断できませんが、おかげでCocoaアプリが保存したファイルをCarbonアプリでオープンする場合などに大きな不都合が生じています。

通常のCarbonアプリケーションは、ファイルタイプによりファイル種類を認識しており、拡張子の取り扱いはFile Exchangeに任せています。例えば、NavGetFile()では、表示したいファイルタイプを指示することで、好みのファイルだけを選択対象としてリストに表示できるわけです。ところが、Cocoaアプリが保存したTIFFやJPEGファイルにはファイルタイプがありません。よって実際はオープン可能なのに、リスト上ではハイライトとなり選択できないという状況が起きてしまいます。加えてCarbonアプリでは、ドラッグ＆ドロップでファイルを取り込めるかどうかの判断にも、ファイルタイプを利用している場合があります。こうした場合、ファイルタイプの無いファイルは、ドラッグ＆ドロップの対象外となってしまいます。このような状況を避けるのには、ファイルタイプがゼロの場合に限って、ファイル名の拡張子をチェックしてファイルの種類を判断する処理を追加する必要があります。ひょっとしたら、こうした面度な作業を代行してくれるAPIが、CarbonLibのどこかにお隠れになっているのでしょうか？

File Exchangeの代用機能（？）なのかどうか分かりませんが、ファイル情報ダイアログに「アプリケーション」という機能があります。これにより、ファイルのダブルクリックで起動するアプリケーションを別物に変更することができます。まずは、ファイルタイプとクリエータを持っているファイルについて調べてみました。

　

設定項目を「特定のアプリケーション」にし、メニューで別アプリを選択してやると、確かに変更後のアプリケーションが起動するようになります。しかしアイコン表示は変わりませんので、クリエータを書き換えたわけではなさそうです。次に両情報を持たないファイルについて調べてみました。

　

すると、前はハイライト表示だった一番下の「アプリケーション変更...」というボタンが有効になります。これでアプリを選べば、新規クリエータとファイルタイプが設定されアイコン表示が変わるのだろうと予想したのですが、どうも違うようです。何も変化がありません...。これは、いったいどういう機能なのでしょうか？謎であります。

Cocoaアプリケーションでファイルタイプとクリエータを設定するために、AppleはCocoa環境からCarbon APIを呼ぶ手法を公開しているようです。しかし、根本的な解決には、Cocoaにファイルタイプとクリエータを扱うためのAPIを用意し、ファイルへの両情報の設定を義務付ける必要があると思います。加えて、Mac OS 9並みのFile Exchangeの実装も早急に実現する必要があるでしょう。
[小池邦人/オッティモ]

カテゴリ：

Browsing Mac OS X》ルート関連記事の追加情報、ルートが無効でもsudoは使えるなど

MDOnlineの2001/4/5号で配信した「Browsing Mac OS X」の“アカウントとルートについて、あえてルートになる必要はない”について、読者のLaylaさんより、御指摘をいただいた。NetInfo Managerを使ってルート権限を有効にしなくても、Terminalからsudoコマンドは使える。記事では有効にしないと使えないと記載したが、訂正させていただく。
sudoコマンドは、「別のユーザになってコマンドを実行する」というコマンドだが、sudoに続いてコマンドを記載する、つまりユーザ名の指定を省略すると、rootのユーザとしてコマンドを実行するのである。ただし、単に誰でもコマンドが実行できるわけではなく、sudoコマンド入力直後に、そのアカウントのパスワード入力が必要になる。Mac OS Xで、NetInfo Managerでルートを有効にする前に、Terminalでsudoコマンドを実行すると、パスワードの入力を要求される。そこで、インストーラで指定した最初のユーザのパスワードを指定することで、コマンドは実行される。ルートとしての処理をいっさいできないようにしたわけではなく、こうしてsudoコマンドを使うという手法だけが提供されていると考えればよいだろう。
もし、ここで、NetInfo Managerを使って、ルートを有効にし、ルートのパスワードを指定したとする。そのような状態でも、sudoでルートとしてコマンドを実行するときには、インストーラで作成したアカウントのパスワードを入れるのである。ルートを有効にしても、sudoでのパスワードはルートではなく、最初に作成するアカウントのパスワードとなる。

さらに、読者の小澤晃さんより、マルチユーザ機能の次のような問題点を教えていただいた。システム環境設定の「ユーザ」でユーザの登録を行うと、/Usersフォルダに、アカウント名と同じ名前のフォルダができ、そこをそのユーザのホームフォルダとする。ただし、アカウントを削除しても、ホームフォルダは残ってしまうのである。その残ってしまったフォルダについては、種類が管理者のユーザでも削除することはできない。どうしても、ルートにならないと削除することができないのである。ルートでの処理をさせないという方針との一貫性がないのではといった御意見だ。
多くのUNIXシステムではアカウントを消してもホームディレクトリを残すということを行っているため、その機能をMac OS Xでは踏襲していると思われる。これは、サーバなどではデータファイルなどの別のアカウントが使うようなファイルも作るようなことがあるからだろう。しかしながら、Mac OS XのようなクライアントOSで、しかもユーザ管理機能がOSとして提供されている場合には、確かにホームフォルダを消滅させてしまうというオプションも用意してもいいのかもしれない。もっとも、それなりのバックアップ機能なども含めてほしいなど、状況に応じた機能が求められることになるだろう。

カテゴリ：Browsing Mac OS X

Browsing Mac OS X》だんだん遅くなるMac OS Xはやっぱり「再起動」しないとだめ？

いきなりタイトルと関係ない話になるが、いろいろなアプリケーションがCarbon化されることはもちろん、歓迎できる。しかしながら、GraphicConverterのCarbon化についてはちょっとがっかりさせられた。筆者はいわゆる「ライターさん」であるので、こうした原稿とともに画面ショットを作成するのであるが、たかだか画面ショットを作成して不要な部分を消すだけのペイント機能しか使わない。いつしか、Photoshopはほぼ使わなくなり、ほとんどの画像処理作業をGraphicConverterで行うまでになっている。レタッチと言っても、単にトリミング以上のことは、今時はライターの手元では行わないのである。必要な部分だけに切り取る作業は、ハッキリ言って、PhotoshopよりGraphicConverterの方がやりやすく手軽で早い。それに、一括変換機能も重宝していて、WindowsのBMPを一気に圧縮TIFFにするなどの使い方をしている。もっとも、GraphicConverterの圧縮TIFFはレイアウトに問題がでる場合もあるのだが、そのあたりはレイアウトするときに適切な処理をしてもらうことにして、とりあえずライター側の作業はそこまででOKなのである。
だから、Carbon版のGraphicConverterが出た時は非常にうれしかった。しかしながら、実際に動かしてみてちょっと勝手が違った。しかも、よく利用する一括変換作業を行うと、いきなり終了してしまう。また、ダイアログボックスの日本語が化けているなど、詰めが甘い点も見られる。いずれにしても、「とにかくCarbonで動かすようにした」というところなのだと思う。あまり、動作チェックなどもしていないのだろう。もちろん、完全なものを出すのが理想ではあるが、そんなことをしていたらいつまで経っても製品は出荷できない。どこで妥協するかは、もちろん、制作者の裁量にかかっている。Mac OS X自体の完成度を考えれば、対応ソフトもある程度のレベルで出荷して、多くの人に使ってもらうなどしてもまれることでより効果的に改良が進むということも考えられる。その意味ではいちいち目くじらをたてる方が発展を疎外するのかもしれないけども、やっぱりこうした状況では、Classic版のGraphicConverterを使ってしまうことになる。早いタイミングでGraphicConverterがCarbon化したことには高く評価はしたいが、残念ながら実際に使っての評価には結びつかないだろう。

さて、Mac OS Xはとにかく「遅い」というのがみんなの一致した意見だろう。しかも、PowerBookやiBookといったポータブルマシンではかなりパフォーマンスが悪いのではないだろうか。筆者のところでは、Power Macintosh G3/300MHz/256MBと、PowerBook G3/400MHz/192KBを使っているのだが、やはりどう見ても前者の方がレスポンスがいいのだ。クロックからすれば逆なのだが、メモリのせいだろうか。いや、iBookではかなりパフォーマンスが悪いということも聞く。一方で、G4マシンではそれなりのパフォーマンスが出ているという話もある。いずれにしても、遅いけども使わざるを得ないというところではある。
何が遅いかというと、やはりFinderの処理と言う点にまず行き着くことになる。フォルダをダブルクリックして、開くのに数秒くらいはかかるときもある。この間合いがとにかくだるい。Mac OS 9でもそれなりにレスポンスには時間がかっていたが、とにかくまずはウインドウが開いた。Mac OS Xではダブルクリックしてしばらく変化がないのである。時間がかかるにしても、ダブルクリックを受け付けたことだけはすぐに分かるような動作をしないと待ち時間はそのままフラストレーションに変わる。また、ダブルクリックしても応答がないなど、いらつかされることもある。とにかく重いと感じてしまう。
アプリケーションを使っていてもそれなりに重いが、Classicアプリケーション内の方がかえってキーレスポンスがいいのじゃないかとも思う時がある。
また、レスポンスが遅いとよけいにいらいらしてあれこれやってしまうものだが、メニュー選択でもやはりそうだった。だけど、クリックしたのにメニューがすぐに消えてしまうと思っていたのだが、よく観察を行うと、メニューが出て来る位置をクリックした後、マウスを動かさないでいれば、出てきたメニューは消えることはない。だから、クリックしておとなしくしばらく待てば、メニューが出てくるので、そこからマウスを動かせばいいといことにに気がついた。メニューがすぐに出てくるのならいいのだけど、現状はそこまでのパフォーマンスはないようだ。筆者も含めて古くからMacintoshを使っている人は、メニュー選択はドラッグしてやりがちだと思うのだけど、そういう作業手順だから手が痛くなることに気がついた。メニューもクリックしておとなしく待ち、メニューが出てきてからまたもやクリックして選択する方がレスポンスが悪い状態では使い勝手がいい。
ただ、それでも、使っているうちに、なにをやっても遅くなるというときがある。仮想記憶に大量のメモリを使っている場合であるような気がするのであるが、これはまったくの勘である。ちなみに、かなり操作が重くなった時に仮想記憶の様子を見たら、約80MBのファイルが7つあった。そのときは、アプリケーションを終了していってもあまり効果はなく、再起動するしかないみたいなのだ。堅牢なはずのOSなのに、こうしたことがあるとなると、やや不安を抱いていしまう。
また、これもレスポンスが悪いというところから来るのだと思うが、再起動やシャットダウン時に、アプリケーションの終了に時間がかかり、終了できないと思って、シャットダウンのプロセスが止まってしまう。再度、アップルメニューなどからメニュー操作をしないといけない。アプリケーションをたくさん立ち上げていると、レスポンスがないのでシャットダウンを中止したというメッセージに何度も出くわし、なかなかスイッチオフに持ち込めないのだ。あっさり、手作業で全部終了してから、シャットダウンや再起動をする方が早いのかもしれない。
Mac OS Xのパフォーマンスのチューニングはまだこれからやるのだと言われてしまうとそれまでなんだが、とにかくFinderの遅いのだけは何とかしてもらいたいと切に願いたいところだ。

カテゴリ：Browsing Mac OS X

メトロワークスがPalm OS向けCodeWarriorのアカデミック版を発売

メトロワークスは、Palm OS向けの開発ツール「CodeWarrior for Palm OS Platform日本語版リリース6」のアカデミック版（教育機関関係者向け販売）を2001年4月13日に発売する。価格は\19,800（通常版は\49,800）で、CodeWarriorセンターより販売される。Windows 95/98/2000/NTまたはMac OS上で稼動し、C/C++を使って開発が行える。GUIベースのレイアウトツールや、エディタ、コンパイラやリンカ、プロジェクト管理など、開発に必要な機能がまとめられており、さらにPalm OSエミュレータ、Palm OSシミュレータなどPalm OS向けの開発機能も組み込まれている。Palm OS SDK 3.5に対応し、VisorやCLIEなどの各社のPalm OS問う才気に対応している。なお、5月31日までに登録を行うと、夏に発売予定の「CodeWarrior for Palm OS 日本語版バージョン7 アカデミック版」への無償アップデートも行う。

関連リンク：「CodeWarrior for Palm OS Platform日本語版リリース6 アカデミック版」を発売
カテゴリ：開発ツール, Palm & PDA

TIL》TIL-J》Mac OS XのFinderを中心とした操作環境についての文書

Tech Info LibraryおよびTech Info Library-Jに掲載された、Mac OS XでのFinderを中心とした操作環境に関連する文書を紹介しよう。

◇Mac OS X 10.0:「開く」および「保存する」ダイアログはユーザの「Documents」フォルダをデフォルトとして設定します
http://til.info.apple.co.jp/cgi-bin/artnum?id=106167JC
◇Mac OS X 10.0: Using Your Home Directory
http://til.info.apple.com/techinfo.nsf/artnum/n106167
ホームディレクトリの意味と重要性についての説明がある。

◇Mac OS X 10.0:「デスクトップには表示オプションはありません」というメッセージが表示される
http://til.info.apple.co.jp/cgi-bin/artnum?id=106208JC
◇Mac OS X 10.0: Message That "There are no view options for the desktop" Appears
http://til.info.apple.com/techinfo.nsf/artnum/n106208
デスクトップの設定は、Finderメニューの「環境設定」で行う。メッセージは将来的には出ないようにする。

◇Mac OS X 10.0: Help Viewer 「指定した HTML ファイルが見つかりませんでした」
http://til.info.apple.co.jp/cgi-bin/artnum?id=106223JC
◇Mac OS X 10.0: Help Viewer "The Specified HTML File Could not Be Found"
http://til.info.apple.com/techinfo.nsf/artnum/n106223
ハードディスク名に/が含まれていると、こうしたメッセージが表示される。

◇Mac OS X 10.0: Applications、Library、System フォルダでの制限されたアクセス
http://til.info.apple.co.jp/cgi-bin/artnum?id=106237JC
◇Mac OS X 10.0: Restricted Access in Applications, Library, and System Folders
http://til.info.apple.com/techinfo.nsf/artnum/n106237
Applications、Library、Systemのフォルダからゴミ箱にドラッグ&ドロップができなくなる場合の対処方法が記載されている。（通常の利用では、できる場合もある。ある種の操作で、Applicationsにある項目の削除などができなくなった場合の対処法である。）

◇Mac OS X 10.0: Dock や「Applications」フォルダに不明なフォルダが表示される
http://til.info.apple.co.jp/cgi-bin/artnum?id=106241JC
アプリケーションがフォルダとして表示されてしまう時があるが、その場合はホームフォルダからLibrary、Preferencesと移動して、LSApplications、LSClaimedTypes、LSSchemesの3つのファイルを削除することで対処できる。

◇Mac OS X 10.0: Applications Do Not Work Automatically if Utilities Folder Is Renamed
http://til.info.apple.com/techinfo.nsf/artnum/n106265
/ApplicationsフォルダにあるUtilitiesフォルダの名前を変更すると、予期しないトラブルに見回れるかも知れない。たとえば、印刷しようとしてもPrint Centerがないといったエラーを出す。フォルダ名は変更しないようにする。

カテゴリ：Tech Info Library-J, Knowledge Base（旧TIL）, Mac OS X

TIL,TIL-J》Mac OS XとiTools、iDiskに関する文書、制限事項などを解説

Tech Info LibraryおよびTech Info Library-Jに掲載された、Mac OS XとiToolsやiDiskに関連する文書を紹介しよう。

◇25275JN:iTools Email: POP3、IMAP プロトコルと Mac OS X 10.0
　http://til.info.apple.co.jp/cgi-bin/artnum?id=25275
Mac OS Xのリリースにあわせて、iToolsの電子メールアカウントへはPOPだけでなく、IMAPでの接続利用もできるようになっている。IMAPはサーバに接続して利用するものであることなどが説明されている。

◇25273JN:iTools iDisk: ファイル名は 31 文字以下で入力してください
　http://til.info.apple.co.jp/cgi-bin/artnum?id=25273
31バイト以上の長さの文字列は警告が出る。Mac OS Xを使っている場合には、保存やコピーするファイルの長さに気をつける。

◇25272JC:iTools iDisk: Mac OS X 10.0 での表示の問題
　http://til.info.apple.co.jp/cgi-bin/artnum?id=25272
iDiskにコピーしたファイルがすぐに表示されないなどの問題がある。ログインしなおすなどの処置をしなければならないときもある。

◇Mac OS X 10.0: How to Set up Application Mail for iTools Email
http://til.info.apple.com/techinfo.nsf/artnum/n75109
Mac OS Xに付属するメールソフトのMailでiToolsのアカウントを自動的に使う方法、手動で設定する方法が説明されている。また、SMTPサーバを接続しているプロバイダが提供するものに設定する方法が記載されている。

◇Mac OS X 10.0: Can’t Save to iDisk’s Software Folder
http://til.info.apple.com/techinfo.nsf/artnum/n75119
iDiskのSoftwareフォルダは読み込みしかできないので、そこにファイルを保存するすることはできない。

◇Mac OS X 10.0: iTools and Internet System Preferences
http://til.info.apple.com/techinfo.nsf/artnum/n75120
Mac OS XでiToolsを使う場合には、システム環境設定の「インターネット」の設定パネルにあるiToolsのタブで適切に設定を行う必要がある。

カテゴリ：Tech Info Library-J, Knowledge Base（旧TIL）, ネットワーク