MOSA Multi-OS Software Artists

「WebObjects Dev Report」　　第46回　　田畑 英和

　Intel Mac上でWindows XPを利用可能にするBoot Campのパブリックベータがリリースされました。Webアプリケーションを開発していますと、動作確認のためにMacもWinも両方必要になったりしますが、1台のマシンで両方が使えるようになるのは便利ですね。また、ノートパソコンを持ち歩いている方でMacもWinも使いたかった方にとっては特に朗報なのではないでしょうか。ただ、デュアルブートですので、OSを切り替えながら使い分ける必要がありますね。

さて、前回はこれまでこの連載で解説してきましたプロジェクトを実際に動かす手順を解説しました。アプリケーション単体として起動に必要なものはすべてご紹介しましたが、今回は今後アプリケーションを拡張するにあたっての改良について解説したいと思います。

◇プロジェクトの改良
　プロジェクトの規模が大きくなればなるほど、1つのプロジェクトが肥大化してきます。1つのプロジェクトの中にすべてのファイルがまとまっているとそれはそれで便利かもしれませんが、それでもアプリケーションの数が増えたりするとプロジェクト間での共通部分をどう扱うかという問題があります。
　たとえば一般ユーザが利用するアプリケーションと、管理者が利用する管理用のアプリケーションを個別に開発するとしましょう。このような場合、データベースは共通のものを利用するでしょうし、そうなるとモデルファイルも共通のものを利用するでしょう。アプリケーションごとに扱うEntityやAttributeは異なるかもしれませんが、共通する部分もある程度はあるはずです。さらにモデルファイルが共通であれば、カスタムEOのソースコードも共通化しておいたほうが効率的です。
　このようにアプリケーション（プロジェクト）間で共通する各種ファイルはフレームワークとしてまとめることができます。ここでまずフレームワークとはなにかですが、WebObjectsでアプリケーションを開発しているのであれば、すでにフレームワークは使用しています。プロジェクトのFrameworksグループの中には、プロジェクトを生成したときに自動的に追加された次のようなWebObjects標準のフレームワークが登録されているはずです。

・WebObjectsアプリケーションにデフォルトで登録されるフレームワーク
-JavaFoundation.framework
-JavaEOControl.framework
-JavaEOAccess.framework
-JavaWebObjects.framework
-JavaWOExtensions.framework
-JavaXML.framework
-JavaJDBCAdaptor.framework

◇フレームワーク
　フレームワークには.frameworkという拡張子がついていますが、その実体はディレクトリであり、システムが提供するフレームワークは次のパスにインストールされています。

・システムが提供するフレームワークのパス
/システム/ライブラリ/Frameworks/

　フレームワークの中身がどうなっているかですが、基本的にプロジェクト上で扱うことのできるファイルは、なんでもフレームワークの中に入れることができます。例えば、JavaライブラリやWOのコンポーネントやモデルファイルなどをフレームワークとしてまとめることができます。さらに、フレームワークから別のフレームワークを参照することもできます。
　フレームワークは異なるプロジェクトから自由に参照することができますので、フレームワークの中で管理しているファイルは複数のプロジェクトから共有することができるというわけです。

◇フレームワークの作り方
　フレームワークの開発方法は、アプリケーションの開発方法と似ています。まず最初にフレームワーク用のプロジェクトを新規作成しますが、このときプロジェクトのタイプとして、「WebObjects Framework」を選択します。
　あとはアプリケーションを開発していたときと同様に、プロジェクトの中にJavaのソースコードを実装したり、WOのコンポーネントやモデルファイルを追加していきます。ただし、アプリケーションとは違いフレームワークを起動することはできません。フレームワークはあくまでもアプリケーションから参照されるものです。
　完成したフレームワークを実際に使用するときにはアプリケーションと同様に、インストールを行ないます。独自に開発したフレームワークは、システムが提供するフレームワークとは異なるパスにインストールします。

・独自に開発したフレームワークをインストールするパス
/ライブラリ/Frameworks/

◇フレームワークの使い方
　フレームワークは、プロジェクトに登録するだけで利用できるようになります。プロジェクトにフレームワークを追加するには、Frameworksグループを選択した状態でCtrl + クリックし「追加」メニューから「既存のフレームワーク…」メニューを選択して、プロジェクトに追加するフレームワークを指定します。
　フレームワークをプロジェクトに追加すれば、フレームワークに登録しておいたファイルをプロジェクトから利用できるようになります。

小池邦人のCarbon API 徒然草（2006/03/17）

〜　アプリケーションのUniversal Binary化（その6）　〜

今回は、Macintosh独自のデータ保存方法「リソース」についてエンディアンの影響を調べてみます。例題として、長い間QuickDrawで利用されてきた画像フォーマットのPicture（PICT）構造体を取り上げます。

まず頭に入れておかなければいけない点は、リソースデータはファイルのリソースフォークにビッグエンディアンとして保存されているということです。例えばリソースデータ内に何らかのサイズを示すlong値が含まれているとすると、その数値フォーマットは必ずビッグエンディアンです。リソースを取り扱う場合にResource ManagerのAPIを使えば、データのエンディアンの違いはシステムの内部処理が吸収しますので、x86環境においてもその違いを気にする必要はありません。ただし、APIを利用せず、直接リソースの内部データにアクセスするような場合には注意が必要です。

以下にx86環境でコンパイルすると正常に動かない例を示します。ここでの処理の対象はGetPicture()で読み込んだPICTリソース（PicHandle）です。setMyControlWellPict()は、PICTリソースをWellコントロール（画像表示用コントロール）に表示するためのルーチンです。Wellコントロールでは、その表示枠としてPICT画像の矩形枠（picFrame）を利用します。よって、矩形枠が大きすぎるPICT画像を小さなWellコントロールに表示する場合には、その矩形枠の再調整が必要になるわけです。setMyControlWellPict()ルーチンの引数fitに1を代入すると、PICT画像の矩形枠をWellコントロールの表示枠から上下左右3ピクセル分小さく合わせて表示することができます。

void setMyControlWellPict( ControlRef chd,short fit,PicHandle pict )
{
    Rect                        brt,srt,frt;
    ControlButtonContentInfo    info;

    if( pict && fit )
    {
        srt=(*pict)->picFrame;                  // PICT画像枠を得る
        OffsetRect( &srt,-srt.left,-srt.top );  // 画像枠を左上原点へオフセット
        GetControlBounds( chd,&brt );           // Wellコントロールの表示枠
        InsetRect( &brt,3,3 );                  // 表示枠を3ピクセル小さめにする
        OffsetRect( &brt,-brt.left,-brt.top );  // 左上原点へオフセット
        fitBounds( 1,&brt,&srt,&frt );          // 矩形枠を調整する自作ルーチン
        OffsetRect( &frt,-frt.left,-frt.top );  // 左上原点へオフセット
        (*pict)->picFrame=frt;                  // 調整済み矩形枠をセットする
    }
    info.contentType=kControlContentPictHandle; // 表示対象をPictureに設定
    info.u.picture=pict;                        // PicHandleを代入
    SetImageWellContentInfo( chd,&info );       // Wellコントロールに表示指示
}

このルーチンがPowerPC用にコンパイルされれば正常動作しますが、x86用にコンパイルされると正常に動かず、画像は正しく表示されません。原因は、srt=(*pict)->picFrameと(*pict)->picFrame=srtの箇所です。(*pict)->picFrameは生のリソースデータですので、その構造体のメンバー（4つのshort値）はビッグエンディアンです。しかし、それ以降のAPIが取り扱うRect構造体のメンバーはリトルエンディアンである必要がありますので、srt=(*pict)->picFrameという処理によりエンディアンの不整合が発生するわけです。

何らかのCarbon APIを用いれば、上記の問題はシステム側で解決してくれるはずです。そこで、PICT画像の矩形枠を得たり設定したりするAPIを探してみました。矩形枠を得るAPIとしては、QDGetPictureBounds()が見つかりましたが、どうもセットする方のAPIは存在しないようです。そこで、Rect構造体メンバーのエンディアンを反転するswapRect()と、PICT画像の矩形枠をセットするsetPictureBounds()という自作ルーチンを用意しました。

void setPictureBounds( PicHandle pict,Rect *drt )
{
    Rect    frt;

    frt=*drt;

    #if __LITTLE_ENDIAN__
        swapRect( &frt );         // x86ではRect構造体を反転させる
    #endif
    if( pict )
        (*pict)->picFrame=frt;    //
}

void swapRect( Rect *drt )
{
    drt->left=Endian16_Swap( drt->left );     // Rect構造体の右の値を反転
    drt->right=Endian16_Swap( drt->right );   // Rect構造体の左の値を反転
    drt->top=Endian16_Swap( drt->top );       // Rect構造体の上の値を反転
    drt->bottom=Endian16_Swap( drt->bottom ); // Rect構造体の下の値を反転
}

void setMyControlWellPict( ControlRef chd,short fit,PicHandle pict )
{
    Rect                        brt,srt,frt;
    ControlButtonContentInfo    info;

    if( pict && fit )
    {
        QDGetPictureBounds( pict,&srt );        // PICT矩形枠を得るAPI
        OffsetRect( &srt,-srt.left,-srt.top );
        GetControlBounds( chd,&brt );
        InsetRect( &brt,3,3 );
        OffsetRect( &brt,-brt.left,-brt.top );
        fitBounds( 1,&brt,&srt,&frt );
        OffsetRect( &frt,-frt.left,-frt.top );
        setPictureBounds( pict,&frt );         // 自作した矩形枠セットルーチン
    }
    info.contentType=kControlContentPictHandle;
    info.u.picture=pict;
    SetImageWellContentInfo( chd,&info );
}

これでOKかと思われたのですが、調べてみるとQDGetPictureBounds()はMac OS X 10.3以上でないと利用できません（涙）。x86環境は必ずMac OS X 10.4以上ですので問題はないのですが、このルーチンをPowerPC環境のMac OS X 10.2xで動かすとクラッシュしてしまいます。そこで、PICT画像の矩形枠を得る場合にも、以下のような自作ルーチンを用意してやっと問題は解決しました。

void getPictureBounds( PicHandle pict,Rect *drt )
{
    if( pict )
    {
        #if __LITTLE_ENDIAN__
            QDGetPictureBounds( pict,drt ); // x86環境ではAPIを利用する
        #else
            *drt=(*pict)->picFrame;         // PowerPC環境ではダイレクトに設定
        #endif
    }
}

void setMyControlWellPict( ControlRef chd,short fit,PicHandle pict )
{
    Rect                        brt,srt,frt;
    ControlButtonContentInfo    info;

    if( pict && fit )
    {
        getPictureBounds( pict,&srt );       // 自作したルーチンに変更する
        OffsetRect( &srt,-srt.left,-srt.top );
        GetControlBounds( chd,&brt );
        InsetRect( &brt,3,3 );
        OffsetRect( &brt,-brt.left,-brt.top );
        fitBounds( 1,&brt,&srt,&frt );
        OffsetRect( &frt,-frt.left,-frt.top );
        setPictureBounds( pict,&frt );
    }
    info.contentType=kControlContentPictHandle;
    info.u.picture=pict;
    SetImageWellContentInfo( chd,&info );
}

とにかく、リソースデータを処理する場合には、そのために用意されているAPIを使うことが肝要です。ただし、Resource ManagerのAPI側でエンディアンを考慮してくれる対象は、Apple社が定義しているリソースタイプ（種類）だけですので注意してください。自分自身でデータフォーマット（構造体）を定義しているカスタムリソースについては、一般的なファイルを読み込む場合と同様、その入出力時にエンディアンの違いを考慮する必要があります。例えば、Metrowerks CodeWarrior付属のPowerPlant Frameworkで用いられているカスタムリソースなどがこれに当てはまります。

カスタムリソースデータと同様なものには、カスタムペーストボードデータやカスタムアップルイベントデータがあります。こうしたカスタムデータのエンディアンを効率よく反転させるために、Apple社はフリッパーと呼ばれるバイトスワップ用コールバックルーチンを組み込めるようにしました。仕組みは簡単で、OSTypeでその種類を判別できるバイトスワップ用コールバックルーチンを定義し、それをCoreEndianInstallFlipper()で登録します（CoreServiceのEndian.hを参照）。

フリッパーの仕組みやCoreEndianInstallFlipper()についての詳細は、以下のURLから参照できる「Universal Binaryプログラミングガイドライン（第2版）」の「データのバイトスワップを行うコールバックの作成とインストール」の章に詳しく解説されています。また、Metrowerks CodeWarriorの付属のPowerPlant Frameworkのソースコードに対して考慮すべき処理内容は「Appendix D: PowerPlantの使用」の章で参照できます。

http://developer.apple.com/jp/transition/

次回は、もう少しリソースについての例題を調べてみます。また、効率の良いエンディアンの反転方法についても考えてみます。

つづく

SqueakではじめるSmalltalk入門　　　第59回　　鷲見 正人

　本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。

前回は、メニューがポップアップするときに起動されるメソッドを“上流”にたどることで、ポップアップメニューにメニュー項目がサブモーフとして登録されるのと同じように、ポップアップメニュー自身もデスクトップにサブモーフとして登録される…という統一的な動作モデルで画面表示が構成されていることを確認しました。なお、システムには他に同名のメソッドがないので「popUpAt:forHand:in:allowKeyboard:」を（タイプ、あるいはコピー＆ペーストして入力後…）選択してからcmd + B（browse it）すれば、再び前回と同じ操作を繰り返すことなしに、当該メソッドのソースコードを一発で再び呼び出せます。

ところで、このメソッド#popUpAt:forHand:in:allowKeyboard:には、前回の内容に絡めてちょっと面白い情報も一緒に含まれています。1回分まるまる使ってしまう少々長めの余談となりますが、立ち寄りついでにそれをご紹介することにいたしましょう。

前回、ポップアップメニューのデバッグハローを単にクリックして（つまりshiftキーを押さずに…）デバッグハローメニューを呼び出してしまうと、解析したいポップアップメニューが消えてしまったのを覚えておられるでしょうか。そこで、デバッグハローから直接、インスペクタをよびだすためにshift-クリックを使用したのでしたよね。

[fig.A]デバッグハローメニューを出すと、元のメニューが消えてしまう

　これはメニューモーフ独特の挙動で、他のモーフはこんなことはありません。で、どうしてこんなことが起こるのかの答えが、実は今、ブラウズしていただいている#popUpAt:forHand:in:allowKeyboard:に書かれているのです。

　このメソッドの最初の部分がそれです。

aWorld submorphs
   select: [:each |
      (each isKindOf: MenuMorph) and: [each stayUp not]]
   thenCollect: [:menu | menu delete]

　#select:#thenCollectという見慣れないメソッドを使っているので、すでに皆さんがご存じの#select:、#collect:に置き換えて、同じことをするコードに書き直してみます（#select:、#collectについは、第34回を参照）。と、申しましても、単に前半を括弧でくくって、thenCollect:以降を#collect:を起動する独立したメッセージにするだけです。

(aWorld submorphs
   select: [:each |
      (each isKindOf: MenuMorph) and: [each stayUp not]])
   collect: [:menu | menu delete]

　ちなみに「select:thenCollect:」を入力して選択後、browse it（cmd +B）して見ることができる定義にも、実は同じことが書いてあります。単に括弧をひとつ省くためだけのメソッドの存在をいぶかしがる向きもあるかと思いますが、かのマーチン・ファウラーはこうした冗長さを称して“ヒューメイン（人道的）”な言語デザインなのだと言っています。

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?HumaneInterface

　さらに踏み込んで、このコードに限っては、次のように書いても同じことになります。

(aWorld submorphs
   select: [:each |
      (each isKindOf: MenuMorph) and: [each stayUp not]])
   do: [:menu | menu delete]

　本来、#select:thenCollect:は、その定義どおり、#select:（パラメータブロックがtrueを返す要素を選別）したコレクションに対して#collect:（パラメータブロックの返値を改めて要素としたコレクションを新たに作成）するときに用いるメソッドなのですが、ここでは返値を捨てている（変数に束縛していない）ので、#do:（各要素についてパラメータブロックを評価）しているのと同じ…というわけです。

察しのよい読者の皆様におかれましては、#select:thenCollect:の説明など見るまでもなく、このコードがデスクトップ（aWorld）に存在するメニューモーフを一掃するためのものであることをご推察いただけていることと思います。試しにこのコードをコメントアウトして、どうなるか確認してみましょう。コメントアウトするには、このコードの前後にダブルクオーテーション「”」を追加して、accept（cmd + S）します。

ただちにコンパイルが終了し、システムはコメントアウトしたコード抜きで新たな挙動を示すようになります。改めて前々回のスクリプトでポップアップメニューを出してモーフとして選択後、デバッグハローメニューを呼び出してみてください。いかがですか？　もう、元のメニューは消えませんよね。

[fig.B]デバッグハローメニューを出しても、消えなくなったメニュー

　こんなふうに、システムの仕組みや動きがどんなふうになっているかを気軽に、かつ、安全に学べるようになっていることも、アラン・ケイが考えるダイナブックの備えるべき（そして、Mac のような“限定”ダイナブックでは削られて久しい…）特徴のひとつであり、暫定ダイナブックシステムとしてのSmalltalkは見事にそれを体現しているわけです。

今回、手を加えたメソッドは、ブラウザのversionボタンで呼び出すことができるバージョンブラウザから一つ前のバージョンを選択して、revert、remove from changesの順にボタンを押して明示的に戻すか、システムを保存せずに終了して再起動することで変更自体をなかったことにできます（後者の場合は、起動後加えた他の変更もすべて失われるので注意してください）。

バックナンバー：

ニュース・解説

　今週の解説担当:木下 誠

———————————————————————-
Boot Camp登場！
———————————————————————-

もうみなさんご承知でしょうが、Intel MacでWindows XPを起動可能にする「Boot Camp」が、Appleより登場しました。MacintoshでWindowsが動くその姿は、正に、衝撃の一言です。

Apple – Boot Camp
http://www.apple.com/macosx/bootcamp/

このBoot Campは、パブリックベータですが、将来、LeopardことMac OS X 10.5に組み込まれることが明言されています。現在はデュアルブートという形を取っていますが、同時起動が可能になるのか、Linuxなどの他のOSも起動可能になるのか、目が離せません。

各種Webニュースメディアからも、速報および詳報が次々と公開されています。

『Intel MacでWindowsが動く「Boot Camp」レポート【インストール編】』
http://pc.watch.impress.co.jp/docs/2006/0406/apple2.htm
『Intel MacでWindowsが動く「Boot Camp」レポート【ベンチマーク編】』
http://pc.watch.impress.co.jp/docs/2006/0407/apple.htm
『Intel MacでWin XPとのデュアル起動を実現、アップルの「Boot Camp」』
http://pcweb.mycom.co.jp/news/2006/04/06/100.html
『衝撃! Mac OS X+XPのデュアル環境を「Boot Camp」』
http://pcweb.mycom.co.jp/column/osx/173/
『パソコン史に残る一大事件! MacでWindowsが“快適”に動く『Boot Camp』の秘密に迫る』
http://mac.ascii24.com/mac/news/misc/2006/04/06/661552-000.html
『【Boot Camp】OS XとWindows XPのデュアルブートが可能なIntel Macの作り方』
http://mac.ascii24.com/mac/news/software/2006/04/06/661554-000.html
『もうみんなMacを買えばいいと思う――Apple純正「Boot Camp」をさっそく試した』
http://plusd.itmedia.co.jp/pcupdate/articles/0604/06/news059.html

わたしも実際にインストールしてみましたが、インストーラの完成度は高く、まったく問題なく進みました。

Boot Campが、Macユーザ、およびPCユーザに、どのような影響を与えるかは、まだ未知数です。ですが、PC業界がWindows Vistaの発売延期により閉塞感が漂う中、次から次へと新しい矢を繰り出してくるAppleには驚かされます。

———————————————————————-
「インテルソフトウェア開発製品Mac OS版」の販売開始
———————————————————————-

前にも紹介したことのある、Intel製のIntel Mac向けコンパイラが、「インテルソフトウェア開発製品Mac OS版」として、正式に発売開始となりました。この開発ツールには、C++コンパイラ、Fortranコンパイラ、マス・カーネル・ライブラリ、インテグレーテッド・パフォーマンス・プリミティブが含まれます。

特に、Intel Macに向けて、FortranおよびC++プログラムのパフォーマンスチューニングを行いたい方に、おすすめでしょう。

MOSAでは、この製品の特別優待価格による購入の案内をするそうです。詳しい内容については、近日中に案内があるそうです。

また、先週行われたインテル・デベロッパー・フォーラムで、「Apple Mac OSおよびマルチコア対応ソフトウェア開発ツール最新版のご紹介」と題したセミナーが開催されました。MYCOM PC WEBで、レポートが公開されています。

IDF-J 2006 – Intel Mac向け開発ツールが提供開始、最適化による性能向上をアピール
http://pcweb.mycom.co.jp/articles/2006/04/08/idf1/

Development Support for Intel-based Macs
http://www.intel.com/cd/ids/developer/asmo-na/eng/255716.htm

販売店である、エクセルソフトによるプレスリリース
http://www.xlsoft.com/jp/services/press/PressRelease_MacOSTools20060407.pdf

———————————————————————-
RSS紹介のドキュメント
———————————————————————-

Web開発者向けに、RSSを紹介したドキュメント、「Delivering Content with RSS for Web Developers on Mac OS X」が公開されています。RSSの仕組みと利用方法が、簡単に紹介されています。

通常のRSSに加えて、Podcastのための仕組みも解説されているところが、Appleらしいです。

Delivering Content with RSS for Web Developers on Mac OS X
http://developer.apple.com/internet/deliveringcontentwithrss.html

———————————————————————-
初出ドキュメント3つ
———————————————————————-

ADCのリファレンスライブラリに、初出のドキュメントが3つ、追加されています。

「Animation Programming Guide」は、Cocoaでのアニメーションプログラミングを解説したもの。NSAnimationおよびNSViewAnimationを使います。

「Apple Filing Protocol Reference」は、AFP (Apple Filing Protocol)のためのコマンドのリファレンスです。”FP”で始まるAPIが含まれます。

「Open Directory Reference」は、Open DirectoryのAPIリファレンスです。こちらは、”ds”で始まる関数になります。

Animation Programming Guide
http://developer.apple.com/documentation/Cocoa/Conceptual/AnimationGuide/index.html

Apple Filing Protocol Reference
http://developer.apple.com/documentation/Networking/Reference/AFP_Reference/index.html

Open Directory Reference
http://developer.apple.com/documentation/Networking/Reference/Open_Directory_Ref/index.html

◇MOSAからのお知らせと編集後記は割愛します◇