Macintosh Developer Online (MDOnline)

2000年12月6日発行号 - Virtural PC 4がリリース

AppStreamやジャストシステムと、あまりMacに関係ないところの記事が並んでいますが、開発環境を考えるときには注目できる点もあるので、あえて記事にしてみました。AppStreamは以前から話を伺っていたのですが、Mac対応はしないのかと聞いたら、あっさりしていないと言われました。今回の発表のタイミングでいちおう記事にしたというところです。Mac対応といってもいろいろあるかと思いますが、WebObjectsのDirect to Javaのメカニズムに、AppStreamのサーバとクライアントの仕組みを組み込むと、非常に快適に利用できるようにならないだろうかなどと考えてしまいます。どんなものでしょうか？　AppStreamは、Red Hearing誌の注目できる10社に入ったとかで、上り調子の会社です。三菱商事やサンから出資があるなど、これからどんどんと露出度は上がるでしょう。ただ、サーバの価格がえらく高いために、誰もが簡単には手を出せませんが、企業システム向けとなるとそうした価格になるのでしょうか。ちなみに、日本のAppStreamのメンバーには元アップルの方が何人もいらっしゃいます。
（新居雅行 msyk@mdonline.jp）

Virtual PCの次期バージョンVer.4が近々リリース、G3/G4に限定されるが高速化を実現

Connectix社は、Mac OS上でPCマシンをエミュレーションするアプリケーションソフト「Virtual PC 4」を2000年12月よりリリースする。Virtual PCを利用すれば、Mac OSを稼動した上で1つのアプリケーション内で、WindowsやLinuxの稼動が可能となる。Ver.4でのいちばんの目玉は、速度が高速化したことで、同社が公開しているデータでは2倍も高速化し、SoftWindowsよりも高いパフォーマンスを示すとしている。ただし、対応マシンは、G3ないしはG4のCPU搭載機となっている。また、Velocity Engineへの最適化も行なうなど、旧機種を切り捨てての高速化を行なった。ただし、Virtual PC自体はClassicアプリケーションである。Mac OS Xでの稼動についての情報は一切なく、Classic環境での動作を保証しているのかどうかも分からない。
他には同時に複数のPC環境を起動できるようになったり、メモリや、ディスク容量の上限が高くなるなど、今風の稼動環境となっている。Ver.3ではUSBをサポートしたものの、ディスクは2GBまでなどやや古いPC環境となっていた。Ver.4ではCD-ROMからのブートにも対応している。FireWireについては、PC環境ではサポートしていないが、FireWireのディスクを共有ディスクなどとして使うことは可能となっている。価格は$199であり、PC-DOS 2000やWindows Me、Windows 98をバンドルしたものが発売される。
高速化と引き替えにG3/G4に限定されたが、現状の利用環境を考えれば不合理な制約でもないだろう。Mac OS Xに関する対応、あるいは情報不足については、やや残念でもある。Classic環境で問題なく動くのかもしれないが、できればネイティブ版でより効率的
に稼動するところを見たいと思うところだ。

関連リンク：Connectix Announces Virtual PC 4
カテゴリ：アプリケーション, Windows

【SnapXShot制作記】アイコン設定は簡単、マウスポインタ挿入にハマる

Mac OS Xの画面撮影ツール「SnapXShot」だが、Mac OS XでStuffIt Delux 6.0を使って圧縮した。何にも考えずにリリースしたが、利用者の方より御連絡をいただき、Mac OS X Public Betaに付属しているStuffIt Expanderでは解凍できても起動ができないとのことだ。CodeWarriorのデバッグの経験を生かし、同じように解凍結果を見てみると、案の定ファイルの実行権限が設定されていない。Public Betaに付属するStuffIt Expander Ver.6.0a5にはバグがあってファイルの情報が完全に復元されないのである。現在、フリーで配付されているStuffIt Expander Ver.6.0はそのバグが直っている。つまり、Ver.6.0の方が新しいわけで、そちらを使って解凍をしてもらいたい。

さて、アイコンについては思った通り、Project Builderを使っているためか、非常に簡単に済んだ。小池さんのプログラマー日記では「ジャイアントアイコン」と呼んでいたのがMac OS Xでのごっついアイコンである。以前なら最大で32ドット四方なので、ビットをマウスでいじって下手なデザインもしたが、128ドット四方をちまちまクリックして描く気にはなれない。もう、これは写真を使うしかない。カメラの写真を撮影しようかと思ったけど、意匠権に觝触しそうだし、なかなかいい題材がない。結局、我が家の家族だったネコのルイくんの顔写真にした（去年に、14歳で他界している）。128ドットの画像ファイルを作り、周辺をぼかすなど、Photoshopでちょっとした画像処理を行なって、TIFFファイルにしておいた。アイコンは、/Developer/ApplicationsフォルダにあるIconComposerを使う。Project Builderとの統合がいまいちなのだが、MOSAのセミナーでアップルの人が使うところを見ていたので迷うところはない。まず、IconComposerをダブルクリックして起動する。そして、128ドットの画像（なぜかいちばん大きな画像がThumbnail）に、写真画像を入れる。あとは、他のサイズの画像の枠、そしてマスクの枠に、ドラッグして埋めていけばいい。いちいちスケーリングするかをダイアログボックスで聞いてくる。そして、プロジェクトのあるフォルダに保存する。

◇IconComposerでアイコンを作成した
　

Project Builderでは、そのアイコンファイルをプロジェクトに登録する。Resourcesのグループに入れるのが順当だろう。そして、プロジェクトの設定を変更するのだが、いちばん説明しやすい方法として、ProjectメニューのEdit Active Target（Command+option+E）を紹介しておこう。すると、プロジェクトの設定ウインドウが出てくるので、Application Settingsのタブを選択し、Icon fileにアイコンファイルのファイル名を入れておく。これはファイル名だけでよく、余計なパスなどは不要なようだ。そして、ウインドウ左上の刷毛のアイコンをクリックして、いちどクリアし、再度トンカチアイコンでビルドをすれば、あっさりアイコンが出てきた。

◇Icon fileのファイル名はキータイプする
　

◇写真をアイコンに持つアプリケーションが出来上がった
　

ここまでできたから、いっそのこと、マウスポインタを入れてやろう！と思ったまではよかったのだが、かなりはまってしまった。もともと、グラフィックス系をバリバリやっているわけではなく、しかも、QuickDrawは最近はすっかりごぶさただったので、道は茨だった。紆余曲折あったのだが、方針編と実装編に分けて説明しよう。
まずは方針だ。理想は、「現在のマウスポインタの形状」がビットマップで得られれば文句はない。だが、結果的にはできないことが分かった。まず、淡い記憶でQuickDrawグローバルがあったはずだと思った。LowMem.hを探すと、あったあった…LMGetTheCursorだ（昔は違うシンボルだったような…）。Appleのサイトで検索…うーん、CarbonはUnsupportedになっている。残念、しかも、Carbonアプリケーションはカーソル画像を取得できないとまで丁寧に書いてある。GDeviceのメンバーにも現在のマウスポインタ画像を取得するものはあったはずだけど、試してみたが、やっぱり何もデータは得られない。データが0になっている。マウスポインタはもっぱら設定するものとしかAPIは用意されていないようだ。Mac OS Xに付属のGrabもマウスポインタはいくつかの形状から選択するようになっている。仕方ないから、常に矢印のポインタをGetQDGlobalsArrowで得ることにした。
得られるデータは、Corsor形データであり、Bit16というシンプルだがやっかいな形式のデータだ。結果的には、そこからPixMap型データを得て、CopyMaskで画面ショットにマウスポインタを上書きするという手はずを踏まないといけない。いろいろサボリを考えてやってはみたが、急がば回れとはよく行ったものだ。最終的には、マジメな方針での実装になった。Technoteの記述もあったので、マウスの形状のPixMap、そしてマスクパターンのPixMapを作った。いずれも、1ビットのデプスのGWorldを作り用意したのである。ただ、Bit16と言っても単なる1ビットの集まりなので、いろいろうまい方法はあるのだろうけど、結局はGWorldにSetCPixcelでドットごとに記述するという方法でビットマップデータを作成した。
余談だが、階乗を取るための演算子は、すっかり^であると思い込んでしまっていた。Visual Basicとかのマクロ系の頭になっていたのである。Cには階乗の演算子はなかった。これで、けっこうはまってしまったのである。
さて、こうした方針で実装を行なうわけだが、短いプログラムながらかなりいじってやっと動くようになった。Bit16のデータからGWorldを作ったのだが、最初はそこで作ったGWorldのPixMapだけを取り出してGWorldは捨てていた。でも、そうしたら、実はPixMapも壊されることに気付き、GWorldを温存してPixMapを使ってからまとめて破棄するようにした。こう書けば簡単な話だが、これに気付くまでに何度も試行錯誤をすることになってしまった。
矢印カーソルのマスクや矢印がきちんとPixMapで得られることが確認できた後は、それを画面ショットに合成する必要がある。座標はGetMouseで得られるので、あとはCopyMaskだということになる。PICTのレコーディングを開始して、CopyBitsで画面の内容を転送し、さらにマウスポインタをCopyMaskで描いても、なぜかマウスポインタが記録されない。さんざん悩み、思い出した…CopyMaskはPICTには記録されないのである。結果的に、画面ショットのデータのPixMapに、マウスポインタのPixMapをCopyMaskで書き込んで、ビットマップを作った。
ところで、PixMapは使い終わるとDisposePixMapするものとばかり思っていたが、なぜか、そこで落ちるのである。しかも、何度か画面ショットを撮影した後で、DisposePixMapで落ちる。落ちた時には、なぜかすでにPixMapのデータが破棄されていて、ハンドルの先には何もない。デバッガで調べたがDisposePixMap直前はハンドルの先にはデータがある。これも悩んだが、Inside Macintoshを見ると、「普通はDisposePixMapを呼ぶことはないよ」と書いてある。同じことがNewPixMapにも書いてある。うーん、確かに、普通のアプリケーションはこの構造体をいじることはないだろうけど、私はある。さんざん悩んだのだが、単にDisposePixMapを使わないで、そのままにしておくことで、きちんと動き始めた。落ちたりはしない。理由をこじつければ、PixMap自体の解放は自動的に行なわれるのではないかということだ。パージ可能なようになっていて、あるタイミングで勝手に解放されるのだろう。だから、PixMapを使うときにはLockPixelsでメモリをロックするのだと言えば、話の辻褄が合いそうだ。だけど、疲れた…。

そんなこんなで、Project BuilderでMach-Oを生成し、アイコンもついてマウスポインタも矢印固定だが出てくるようになった。ちょっとは進歩はしたわけだが、そろそろ次は、WaitNextEventによるぐるぐる回しをやめて、Carbon Event Managerを使う番ば回ってきそうだ。

関連リンク：SnapXShot
カテゴリ：グラフィックス, ProjectBuilder/Interface Builder, SnapXShot制作記

Javaアプレットを“ストリーム”して高速化するAppStream

Javaの高速化技術を持つAppStream社は、日本法人の設立などの発表を行なった。Macintosh環境とはやや離れるが、興味深い技術であるので、紹介したい。AppStream社は1999年に設立され、本社がパルアルト、開発をテルアビブで行なっている。現在150人ほどの従業員がいて、このほど日本法人も設立した。同社の特徴的な製品はJavaのアプレットの実行速度を高速化するサーバを販売する。特にAppStream向けに作ったものではなく、既存のアプレットをAppStream社のサーバを利用することで、実行速度が早くなるというわけだ。仕組みは次の通りだ。Javaのアプレットは、たくさんのクラス定義から成り立っている。一般には1つのアプレットを稼動させるのに、すべてのクラスをダウンロードしないといけないので、その間の待ち時間が発生する。しかしながら、AppStreamサーバ経由でアクセスすることで、必要なクラスをダウンロードした段階で実行が開始される。アプレットを細かく分けて、あたかもストリーミングを行なうかのような動作で、クライアント環境に届けるというわけだ。そのため、最初のアクセスで非常に小さいものの、稼動しているプラットフォームに依存したAppStreamのドライバをダウンロードする。そのドライバを経由することで、アプレットの一部分のダウンロードだけで実行できる仕組みができるということだ。さらに、ダウンロードした結果から、次に呼び出されるクラスの予測を行なうことで、最適化されたソフトウエアのストリーミングも行なう。さらに通信経路上では圧縮を行ないさらに時間をかせいでいる。クライアント側では独自にキャッシュを持っていることから、さらに何度も同じアプレットを動かす場合の高速化も図っている。クラス単位でのバージョン管理もできることから、効率的でかつ自動化されたバージョン管理も行なっている。メガ単位のアプレットになると、体感上は数倍あるいはそれ以上の効果を得ることになる。ただし、残念なことに、Mac版のAppStreamドライバは開発されていない。
ただし、携帯電話向けのドライバが開発されており、韓国のLGテレコムの製品にドライバが組み込まれて出荷され始めている。Javaベースの携帯向けアプリケーションを、条件の悪い通信状況でも効率的に動かす仕組みとして機能する。
また、デジタル家電でJavaやリアルタイムOSの機能を果たす基本ソフトである「JBlend」を開発しているアプリックスと、アップストリーム社の提携についても発表された。JBlendにAppStreamのドライバを組み込むことにより、JBlend対応機器でのJavaアプリケーションのより効率的な実行を見込むことができる。また、アプリケーションの必要なところだけをダウンロードして実行することができるため、諸機能を1つに統合したアプリケーションを作っておき、メモリの余裕のあるデスクトップマシンではそのまま稼動させるとする。そして、AppStreamに対応した携帯機では、そのアプリケーションの必要な部分だけを取り込んで実行するということも可能となる。アプリケーションをわざわざ各種の機器向けに改造する必要もなく、また、メモリなどのリソースの少ない機器でも大きなアプリケーションを動かすことにつながるなど、発展性の高い技術として注目できると、アプリックスの代表取締役である郡山龍氏は説明をした。
AppStreamサーバはWindows NT/2000とSolaris版があって、サーバあたり360〜1320万円となっている。同時アクセス数で価格が変動する。AppStream社では、こうしたデータのセグメント化技術や予測技術を利用して、2001年にはHTMLやサーバベースのWindowsアプリケーションの実行を高速化する製品も投入予定となっている。

関連リンク：AppStream
カテゴリ：Java

ユーザ辞書をネットワークを通じて共有できるATOK14はMac版も開発中

ジャストシステムは、来年初頭から始まるインターネットサービスに関する記者会見を開いた。先にMacintosh絡みの話をまとめておこう。2001年2月9日にWindows向けの一太郎11と花子11をリリースする。そこではATOK14という新しいバージョンのインプットメソッドが投入される。ATOK14については、発売時期は未定だが、Mac OS版やLinux、Windows CEやPalm OSのバージョンをリリースする予定もあるという。少なくともMac OS向けの開発は行なわれていることは明言した。ATOK14には変換処理などの向上に加えて、ユーザ辞書やお気に入り辞書（短文登録のような機能）をネットワークで共有するサービス「ATOK Sync」というサービスを利用できることだ。会社と自宅や、あるいはデスクトップとノートなど複数の機種、さらには異なるOS間でかな漢字変換の1つの重要な環境要素となるユーザ辞書を共有できることになる。具体的にはサーバ上にあるデータを同期することで、サーバとクライアントの辞書の内容を合わせるという手法を用いているため、変換のたびにサーバアクセスするというものではない。このサービスは「一太郎Web」の1つのサービスとして提供するため、一太郎Webに会員登録することでサービスを受けられるようになる。
また、インターネットサーバで文書ファイルなどを保管するInternetDiskサービスについても内容が紹介されたが、これはWindowsのみで使える。というのは、Windowsで稼動する専用ソフトを使うタイプのサービスだ。サーバ上の内容とクライアントのフォルダの内容を、ファイルの日付時刻を手がかりにより新しいものに更新するといった手法で同期を取り、クライアントとサーバの間でファイルのやりとりを行なうといったものだ。一太郎11や花子11の利用者には50MB、両製品のバンドル版は100MBの領域がもらえる。将来的にはデータ変換やファクス送信、HTMLによるファイルの公開などのサービスも行なう。従って、直接、一太郎などが文書ファイルをネット越しに開くという機能ではなく、あくまで、クライアントとサーバでの同期を行なうというのがポイントとなっている。これは2001年2月9日より利用できるようになる。FTPを改良したプロトコルを使っているとのことだ。
いずれにしても、アプリケーションソフトウエアのインターネット対応という点では、具体的に動き出す事例として注目しておく必要はあるだろう。

関連リンク：インターネットの新サービスを強化した「一太郎11」、「花子11」来年2月9日（金）発売
カテゴリ：アプリケーション, Windows

REALbasic 3.0a14がリリース、プロジェクト設定をXMLで入出力

Real Softwareは、Basic言語を基調にしたビジュアル開発ツール「REALbasic」の次期バージョンVer.3.0のアルファ版のリリース14を公開した。REALbasic 3.0は、Carbon対応しており、Mac OS Xで稼動するネイティブなアプリケーションの生成が可能となっている。新しいリリースでは、プロジェクトの設定をXML形式で読み書きできる機能や、データベース関連の機能が追加された。また、PostgreSQL関連の機能のバグ修正など、不具合の解消もいくつか行なわれている。

関連リンク：REALbasic 3.0a14
カテゴリ：REALbasic