● ToolBox API徒然草（2006/10/12）

今回は、もう少し詳しくDEPRECATED APIを調査してみたいと思います。いったい、どんなAPIが消え、どんなAPIが生き残ったのか？APIの差し替え作業をするにも、まずこの点を把握しておかなければ始まりません。

どのような種類のAPIがDEPRECATEDの洗礼を受けるのかについて、何かしらはっきりとしたルールが存在すれば使う側も判断しやすいのですが、どうも、そうした明確な基準は提示されていないようです。しかし、Carbon Frameworkのヘッダーファイルを調べてみると、まず最初にQuickDraw関連のAPIがほとんどダメ（DEPRECATED指定）だと言うことに気づきます。QuickDraw関連のAPIが定義されているヘッダーファイルは、QD.hというヘッダーファイルにまとめて記載されていますので、その個々の内容を調べることで大まかな状況を把握することができます。

ここで対象となるヘッダーファイルは、QuickDraw.h、QuickdrawText.h、PictUtils.h、QDOffscreen.hなどです。前回も少しお話しましたが、QuickDraw.hでDEPRECATEDと指定されていないAPIは全部で60弱です。QuickdrawText.h、QDOffscreen.h、 PictUtils.hの3つについては、ほぼ全てのAPIがDEPRECATEDとなっています。DEPRECATED指定を免れたAPIを分類してみると、QDBeginCGContext()やQDEndCGContext()、そしてQDSwapPort()のように、名称の先頭に「QD」とついたAPIはほとんど生き残っています。これらはMac OS X以降に導入された比較的新しいAPI群です。QuickDraw.hでは、こうしたAPIが20程度存在しています。

それ以外は、不思議なことに、GetPortBounds()、GetPortForeColor()といったCGrafPortの情報を得るためのAPIが結構生き残っています。GetPortBitMapForCopyBits()も、そのうちの一つですが、 この情報が必要であるCopyBits()がDEPRECATEDなのに、何故にこのAPIのみが生き残っているのかはかなり謎です（笑）。この状況を見ると、GWorld（オフスクリーン用CGrafPort）については、それを用いることを禁止したいようですが、CGrafPort自体を無くしてしまうことはないようです。システムの深淵に、まだどうしても外すことができない「理由」が存在しているのかもしれません。GetPortTextFont()、GetPortTextFace()、GetPortTextMode()、GetPortTextSize()などもDEPRECATEDでないのが本当に不思議です。

QuickDrawのメイン画像フォーマットであるPictureを操作するAPIは全滅です。ただし、既に保存されている画像ファイル（PICTファイル）を取り扱いたいケースは多々ありますので、CoreGraphicsで描画を行う時に必要な情報を得るためのAPIが別途用意されています。それらは、QDPictToCGContext.hというヘッダファイルに記載されています。また、Polygonを操作するAPIは全滅ですが、Region（任意領域）については、RgnToHandle()やIsValidRgnHandle()が生き残っています。これを見ると、システム内部でのRegion利用が根絶されたわけではなく、Window Manager関連などでは、まだその使用が継続されているようです。ただし、Appleとしては、徐々にRegionをCoreGraphicsの「Shape」に切り替えたいと考えているようです。Shapeに関してはHIShape.hを参照してみてください。

現在のMac OS Xネイティブ描画システムはCoreGraphics（Quartz 2D）ですから、何らかの描画においては、そちらのAPIを代用すれば、ほとんどのケースは問題ないはずです。ところが、QuickDraw.hでは、描画に直接関係していないAPIもDEPRECATEDとなっており、その処遇に納得いかない場合が多々あります。例えば、Rect構造体を操作するSetRect()やOffsetRect()といったAPIがそれです。ちなみに、Window ManagerのCreateNewWindow()（こちらは当然DEPRECATED指定でない）では、以下のように引数としてRect構造体を渡す必要があるわけです。よって、SetRect()ぐらい残しておいてもバチは当たらないと思うのですが...どうなんでしょうかねぇ？

extern OSStatus CreateNewWindow(
WindowClass windowClass,
WindowAttributes attributes,
const Rect * contentBounds,
WindowRef * outWindow )

まあ、このレベルのAPIであれば手間さえ惜しまなければ、以下のように自作の代用ルーチンを用意すれば問題は解決します。しかし、CopyBits()、CopyMask()、SeedFill()、BitMapToRegion()といったハイエンドAPIは、ベテランプログラマになると描画処理の目的以外でも色々と活用しているケースが多々あり、こうした有用なAPIがなくなり、かつCoreGraphicsにその代用品が無いとなると、非常に困った事態に遭遇することになります。筆者が一番頭をかかえているのはこの点でして、そうしたAPIは何とか残しておいて欲しいのですが...まあ、無理なんでしょうね（涙）。



こうして色々なヘッダーファイルを調べてみると、最初は、システムのパフォーマンスや安定性に直結するスレッドセーフや64bit対応に不向きなAPIが、そのままDEPRECATEDに指定されているのかと考えたのですが、どうやらそうでもなさそうです。GWorldやPictre同様、Pascalストリングス（Str255）やファイル保存場所を指示するFSSpec構造体を引数に渡すAPIは、ほとんどがDEPRECATED指定を受けているようです。ところが、Mac OS X登場時には「風前の灯火」と噂されていた（笑）Resource Manager（Resoure.h）には、何故だかDEPRECATED APIがひとつも存在しません。システムの進化の「都合」が色濃く出ているようで、実に興味深い結果です。

さて、自作アプリケーションのメイン処理の中心として活躍していたAPIが突然消えてしまったら、デベロッパーは途方にくれてしまいますよね。そうした事態を避けるために、Apple社は何年かかけて少しずつ代用APIを準備してきました。次回は、そうした代用APIを取り上げ調査してみたいと思います。