Browsing Mac OS X》Carbonアプリケーションでロングファイルネームに対応するには（2）
カテゴリー
Mac OS X, Browsing Mac OS X
作成日
2001/3/31 17:10:3
作成者
新居雅行
□Resource ManagerはFSRef対応していない ここで注意しないといけないのは、リソースというものの扱いだ。リソースはMac OSでの独特なシステム機能と連動したデータであったが、Mac OS Xではその位置付けは大きく変わったと言えるだろう。だが、従来のようなリソースの利用も可能で、Resource Managerは利用できる。HFS+のように複数のフォークに対応したボリュームだけでなく、UFSボリュームでもリソースは見えないところに別ファイルを作るなどして、アプリケーション側から見れば、リソースフォークとしてきちんと使えるようになっている。ただし、Resource ManagerはFSSpecでのファイル指定にしか対応していない。そして、どうもFSRefとしてリソースの処理を行う機能は付け加えられる気配もない。つまり、もはや過去との互換のためだけに用意されている機能なのである。Mac OS Xのパッケージ化するファイルではもはやリソースは定義しなくても、ファイルタイプとアイコンの対応付け、つまりBNDLリソースの設定内容などを記述できるようになっているのである。つまり、リソースフォークのないアプリケーションもありとなっている。 リソースは確かにユニークな機能ではあるが、メモリを節約したりやりくりするという点では昔のハードウエア環境ではそれなりに意味があった。しかしながら、仮想記憶がより充実したMac OS Xでは、リソースであろうが、それを一気に読み込んでメモリに展開しようが動作上はあまり違いはないと言える。むしろ、後者の方がパフォーマンスはかせげるのではないかと思われる。別々のファイルに保存するなんて…と思うのなら、それはパッケージという仕組みを利用することで、利用者からは1つのアイコンとして見えるようにできることで対応できるだろう。オブジェクト指向が当たり前になっているだけに、リソースとしてデータの固まりをシステム側で管理しなくても、それに匹敵する機能は言語やAPIで用意されている。だから、リソースとして保存していたものは、これからは別のファイルにふつうにデータフォークに保存して出し入れするという方が問題は少ない。特に、異なるプラットフォームを経由するようなインターネットの世界を考えた場合、リソースの存在によってMacintoshが特種扱いされてしまうということも避けることができる。やはり標準に従うという考え方からすると、リソースの存在は特異なものに見える。 リソースがなくなることを惜しむ声もあるが、これまでもユーザサイドには見えなかったものだ。使う側にとってリソースであろうが別の手法であろうが関係ないわけだし、開発する側も新たに作る部分からはリソースを別の手法に置き換えればいいだけである。ある程度の年月をかけて、リソースは使われなくなるだろう。それを見越してResEditのアップデートは止まったのかも知れない（とは言え、止まったのはえらく前なんだけど…）。