ども。調子に乗って Palm に手を出してしまった石畑です。
公開しているソフトは『〜 for CLIE』ですが、開発当初は『〜 for PalmOS』にするつもりでした。「まうじゃん」のPalmOSへの移植については随分前から要望をいただいており、Pocket PCやシグマリオンへの移植が一段落ついたので、ちょっとやってみようと思ったんです。はい、調子に乗ってますね。
Pocket PCやシグマリオンはOSがWindowsCEですから、Windows用ソフトの移植は割と簡単です。画面レイアウトの変更には苦労しますが、ソースコードの多くは流用できます。でもPalmへの移植はも少し大変です。OSが違うから、アーキテクチャが違うし、使っているAPIも取っ替えないといけません。あ、APIっていうのは、OSへの命令の仕様みたいなものです。ま、とにかく大変なんです。でもやってしまうところは調子に乗っているとしか言えませんね。
とは言え、この手の作業は実は初めてではありません。Java への移植をしてますから。まぁ、それはいいとして・・・
Palm版開発で最初に悩んだのは画面サイズです。Palmの基本画面サイズは160x160ピクセルです。最近の320x320、あるいはそれ以上の高解像度表示は、OSレベルでは基本的にPalmOS5以降での対応になっています。私は旧バージョンのOSでも動作させたいと考えていましたので、とりあえず160x160での画面レイアウトを考えてみたんですが、どうしても納得のいくレイアウトができないんですよ、これが。でも、だからといって高解像度をベースにしてしまうと、必然的にOS5以降のみの対応になってしまうんです。
OS5搭載機の普及は少しずつ進んでいるようですが、旧OS搭載機を使用しているユーザもたくさんいます。この状況でOS5専用ソフトにしてしまうのは、もったいないというか、つまらないというか、嫌な感じです。だいたい、CLIEは結構前から高解像度対応だったじゃないですか。そう、CLIEがOS5になる前から独自の機能拡張で高解像度に対応してたのは周知の通りです。OS5専用ソフトにしてしまったら、その「高解像度対応旧OSクリエ」で動かなくなっちゃうじゃないですか。でも、「PalmOS用ソフト」として公開するには、OS5専用ソフトにするしかないのでは？ いや、「PalmOS5版」と「CLIE版」を作ればいいんですよ。でもこれは面倒くさいでしょ。バイナリが複数できてしまうと管理しにくくなるんですよ。ほら、マイクロソフト社だって64ビット版Windowsのバイナリを1本に絞ったじゃないですか（笑）。じゃぁ、「PalmOS5とCLIE両用バージョン」を作るってのは？ これも面倒くさい、というか、さっきのとたいして変わらないですよ。確かにバイナリは1本になりますけど、書かなきゃいけないコードの量はほとんど変わりません。動作確認も大変ですし。
とかなんとか考えているうちに気付いたんですよ。PalmOSは今過渡期なんです。Windowsで言えば、Windows3.1からWindows95への移行期みたいなものなんです、きっと。え？そんなのとっくに知ってましたか？こんなの常識ですか？ ごめんなさい、Palm文化にはあまり詳しくなかったもので・・・
で、とにかく困りに困った末にたどり着いた結論が、『〜 for CLIE』なんです。そう、CLIEのハイレゾ機能専用ってやつです。日本で一番売れているPalm機がCLIEなのは間違いないですし、私の周りにいるPalmユーザーもみんなCLIEですし、とりあえずCLIEを抑えとけばいいかな、という感じです。「少数派を切り捨てる気か！」とか言われそうですが、そんなこと言っても大変なものは大変なんだから仕方ないんですよ。とりあえずCLIE版がうまく動いたら、その後でOS5版も考えるってことでいいでしょ。
と言うわけで、とりあえず開発ターゲットはだいたい決まったので、今度はPalmOSでのプログラミング方法の勉強です。「そっちを先にやるべきじゃん？」とか思う方もいるかも知れませんが、これでいいんです。C/C++が使えることは分かってましたから言語に関する懸念はありませんでしたし、アーキテクチャが違っても人間の考えることはそんなに変わるものではないですからどうせWindowsのアーキテクチャとそんなに変わらないだろうと踏んでいたんです。と言うわけで、とりあえずGoogleで検索！ ほらいろいろ出てきましたよ、初心者向けのPalm開発サイトが。読んでいくと・・・ほらやっぱり考え方はWindowsと大差ないじゃないですか。これなら割と楽ができるかも知れないですね。
開発の見通しがついたので今度は開発環境をどう整備するかです。開発環境って言うのは、要するにコンパイラやデバッガやエミュレータのことです。これらがないと、作りたくても作れません。ちなみに実機（CLIE本体）はこの時点では用意する気はありませんでしたし、実際に本体を購入したのはずっと後です。だってほら、先に買っといて「結局できませんでした」とかになっちゃったらバカみたいじゃないですか。それに、どうせ買うなら良い機種にしたいですし、開発期間中にもっと良い機種が発売されるかも知れないじゃないですか。第一、開発の初期段階ではエミュレータで十分なんですよ。実機での動作検証は意外とやっかいだったりしますから、最後にやればいいんですよ。というわけで、この時点では実機は買いません。じゃ、コンパイラとかはどうするかですが、調べたところ選択肢は2つあるみたいです。無償で利用できるコンパイラ gcc を使うか、商用コンパイラの CodeWarrior （メトロワークス社）を使うかのどちらかです。どちらを使う場合でも、エミュレータについては無償提供されているものを使えば良いようです。さて、無償を取るか商用を取るかの選択ですが、結局商用を取りました。私も以前は emacs+gcc でプログラム書いていた頃があったのですが、最近はVisual C++に毒されてすっかりヤワになってしまいました、ていうか統合開発環境万歳！
CodeWarriorを買いました。税込み4万円弱。ちょっと痛いです。これでもう後戻りはできません。突っ走るだけです。
まずはCodeWarriorのパッケージに入っていたチュートリアルをやってみました。チュートリアルっていうのは、「ソフトの開発はこんな感じでやるんだよ」ってなことを、実際に簡単なソフトを開発しながら理解していきましょう、ていうやつです。ソフト開発の例題ですね。このチュートリアル、いくつか不備があって（どんな不備だったかはもう覚えてないんですけど）何回か引っかかったんですけど、Palmでのソフト開発のだいたいの考え方は分かりました。後はSDKのドキュメントとにらめっこしながらソースコードを書き換えたり書き足したり削ったりしていくだけです。あ、SDKっていうのは、そのOSの機能やらサービスやらをアプリケーションソフトから利用するために必要になるもろもろのツールやらファイルやらを集めたツールキットのことで、PalmSource社のWebサイトから入手することができます（CodeWarriorにも入っていますが、やっぱり最新版を使いたい）。それと今回はCLIEのハイレゾ機能を使うのでソニーが提供しているSDKも必要です。これはソニーのWebサイトから入手できました（これもCodeWarriorに入っていますが最新版の方が良いでしょ）。
さて、やっと開発を始めるわけですが、開発と言っても今回は移植です。ソフトの移植ではいろいろ注意しなければならないことがあります。今回注意しなければならない箇所は以下の通りです。
意外にも一般にはあまり知られていないようですが、PalmOSは16ビットOSです。PalmOS5になって、やっとOS内部が32ビットになりましたが、「アプリケーションの基本は16ビット」ということのようですから、そういう意味では未だに16ビットOSです。それに対して「まうじゃん」はWindows95をターゲットにして書かれており、当然32ビットベースです。そう、int型のサイズが違うんですよ。ソースコードをそのまま流用すると、これが原因で不具合が発生する可能性があります。一番手っ取り早い方策は int 型を全部 long 型に変えてしまうことですが、それでは動作が遅くなってしまいますし、プログラムサイズが大きくなってしまうかも知れません。つまり、一つ一つチェックして、必要な箇所だけ long 型に変えていかなければいけません。
次にバイオオーダーですが、これは省略します。解説が面倒ですし、PocketPC版を開発する際に対策を講じておいたため今回はあまり気にする必要はないでしょう。
タイマーイベントというのは、一定時間が経ったことをプログラムに知らせてくれる便利なイベントです。「まうじゃん」では、牌を捨てるスピードや牌の点滅の間隔なんかの測定にタイマーイベントを使っています。ですがPalmOSにはそういった機能がないようです。しかたがないので、常に細かい時間でメッセージループがぐるぐる回るようにして、その回転数で時間を計測するようにしました。あまりスマートな方法ではありませんがしかたありません。
そして割と困ったのがマルチウィンドウシステムについてです。Windowsでは、その名の通りウィンドウシステムが提供されます。WindowsCEを採用しているPocketPCでも、OSレベルでマルチウィンドウシステムが提供されています。ですので、PocketPC版ではその機能をちょくちょく使っています。ですがPalmOSはそんな便利な機能を提供してはくれません。「フォーム」という、ウィンドウっぱいものを表示させることはできるのですが、位置を移動させたり、裏にあるフォームで作業させたりすることはできないみたいです。なんとか楽して解決できないか考えたのですが、どうも楽はできそうにないので、自前でウィンドウシステムもどきをこさえることにしました。
とまぁ、いろいろとあるわけですけど、なんとかなるものです。というわけで、移植作業スタートです。ガシガシ書いていきました。
さて、メインの部分がだいたいできてきました。こうなると実際に動かしてみたくなるのが人情というものです。というわけで、CLIE用エミュレータ（ソニーのサイトから入手できます）起動！実行！ をを！いろいろバグってるけど一応動いてるみたいです。感動です。こうなると俄然やる気が出てきます。バグ部分を直して実行。さらに直して実行！・・・
・・・ん？ エラーが出ました。なんか、変なメモリにアクセスしちゃったみたいです。割とありがちなエラーです。そう、エラーメッセージ自体はありがちなんですが・・・。デバッガを呼び出しても問題箇所が表示されません。普通は問題が発生した部分に誘導してくれるのですが、誘導してくれません。ていうか、プログラムに直接関係なさそうなモジュールで止まってるんですけど。呼び出し履歴にプログラムのモジュールが表示されてないってのは、一体どういうことなんでしょうか？
実はこのエラー、未だにときどき出ますし、原因も不明です。でも、「まうじゃん」と関係ないプログラムを動かしても同じエラーが出ますので、たぶん「まうじゃん」の問題ではないと思います。実機ではこんなエラー出ませんから、エミュレータとソニーのROM間の問題じゃないかと踏んでいるんですが、どうなんでしょう？
そうそう、エミュレータと言えば、Palmのエミュレータには2種類あるんです。ひとつはPalmOS4.xかそれ以前のOSをエミュレートするためのもので、もうひとつはPalmOS5.xをエミュレートするためのものです。CLIE用にもこの2つが用意されています。上で書いたエラーが発生するのは前者です。では後者はどうなのかというと、これも私の環境ではうまく動作してくれません。「文字を描画する」操作をするプログラムを作ってこのエミュレータで実行すると、必ずエラーが発生するんです。原因は不明ですが、これでは話になりません。前者は先のエラーは発生しますがいつも発生するわけではない（ボタンの操作をすると発生することが多い）ので我慢できます。とにかく、結果としてエミュレータでのPalmOS5での動作検証はできなくなりました。
（2004年3月6日追記）
その後いろいろと調べた結果、プログラム側の問題であることが判明しました。現在は正常に動作しています。お騒がせして申し訳ないです。CodeWarriorが自動生成してくれたコードを、よく確認せずに使ったのでバチが当たったみたいです（それにしても、あのコードはちょっとまずいと思うのですが・・・）。
このような妨害（？）はあったものの、開発は順調に進みました。普通に遊ぶ分には問題ないレベルまでできてきました。
ここで新たに問題になったのがサウンドをどうするかということです。牌を捨てたときの音や、「ポン」「チー」の声です。PalmOSは昔からサウンド機能を提供しています。ビープ音という、電子ブザーの音を提供しています。サンプリング音にOSレベルで対応したのは、やはりOS5からのようです（例外はあるようですが）。でもこんなことではもう挫けません。なんせ『for CLIE』ですから、CLIEのサウンド機能を使っちゃえばいいんですよ。CLIEはずっと前から音が出せたはずです。CLIEには独自のサウンド機能があるはずです。それを使うんです。では、オープン・ザ・SDK・オブ・クリエ！
・・・ない。ないです。サウンド機能のことなんか、どこにも書いてありません。一体どうなっているのでしょう？ まさか、非公開ですか？ 仕様非公開ですか？ いや、どこかにヒントがあるはずです。こうなったらソニーのサイトを調べまくるしかありません。
・・・ありました。ありましたよ。古いSDK（のドキュメント）にはちゃんとに書いてありますよ、サウンド機能が。こりゃいったいどういうことなんでしょう？ 新しいSDKではソニー独自のサウンド機能をサポートしないのでしょうか？ 新しいCLIEではソニー独自のサウンド機能が動かないのでしょうか？ OS5標準のサウンド機能を使えということなのでしょうか？ それならそれでも構いませんから、そのことをどこか分かりやすいところに書いておいて欲しいものです。少なくとも最新のSDKには事情を書いておくべきだと思うんですが、何か書けない理由があるのでしょうか？（ソニーのサイトには「PalmOS5.2.xを採用するクリエではOS5のサウンド機能が使えます」という趣旨の説明があるのですが、これだけでは分からなさすぎます。）
さあ困りました。古いソニーSDKに書いてあるサウンド機能を使うべきか、旧OSでのサウンド再生はあきらめてOS5の場合だけサウンドが出るようにするか。『for CLIE』なんだからソニーSDK使えば良いじゃん、と思う方もいると思いますが、話はそこまで単純ではありません。最新のSDKに書かれていないと言うことは、ソニー自身がサポートを打ち切った可能性があるということです。そして最新のCLIEでは機能しない可能性があるということです。じゃ、両方のサウンド機能に対応させれば良いのでは？ってことになりますけど、たとえそうしたとしても実機での動作検証ができない可能性がある（クリエを2台用意しなければならなくなるかも知れない）から、それはそれでやっかいです。ホント、嫌な感じです。
で、結局どうしたかと言いますと、OS5標準のサウンド機能を使うことにしました。どのみち実機での動作検証は必要になりますし、実機を買うんならOS5機になるでしょうし、確実に分かっていることは「最新のCLIEではOS5標準のサウンド機能が使える」ということだけですから、妥当な線でしょう。ソニー独自サウンド機能には後からどうにかして対応させるということで決着です。
さてこれでだいたい出来上がりました。理論上はですが。ついに実機での動作検証です。と言ってもまだ実機がありません。エミュレータをいじりまくってたのでどんな機械なのかは分かっていたのですが、実機は持っていなかったんです。そう、買わなければなりません。さっそくソニーサイトにアクセス！ブツを物色です。
ん〜、いろんな機種がありますねぇ。旧OSの機種も現行モデルにあるんですね。値段的にはTJ25が魅力的だけど音が出ないんじゃ話にならないですねぇ。NX80はいろいろできて楽しそう（←すでに目的を忘れている）だけどちょっと高いなぁ。う〜ん、どうしよう。やっぱりユーザーの評価も見た方が良いな。検索！というわけですっかりお買い物ルンルンモードです。しかし、こうやって調べているうちに発見してしまったのです。もうすぐ発売される新しいCLIEの存在を・・・
クリエ好きならもうお気づきでしょうが、この2月に発売された新しいCLIE、TH55とTJ37がそれです。この2機種のスペックを知ったとき、もはやこのどちらかしか考えられなくなっていました。最新OSを採用し、サウンド機能を搭載しています。特にTH55は無線LANを標準装備し、カメラ機能も内蔵して、バッテリーの保ちも良く、それでいて値段も低く設定されています。もうこれしかないでしょう（←すでに目的などどうでも良いと言えます）。
というわけでTH55を入手しました。39800円（税別）−13%ポイント還元です。これまた痛いですけどちょっと幸せな気分です。
早速このマシンにインストールして実行です。おおっ！動きました、動きましたよ。感動です。動いて当たり前なのかも知れないですけど、感動は感動です。
でもやっぱり細かいところでバグってます。エミュレータ（+OS4のROM）での動作とは細かいところで違いますね。OS5でいろいろ変わったのは確かみたいですね。でもこれはたいした問題ではありません。この程度の差異はソフト的に割と簡単にカバーできます。それよりも驚いたのは、「遅い」ということです。コンピュータプレイヤーの思考に1秒以上かかることがあるんです。この程度であれば許容範囲内ですが、単純に驚きました。PDAとは言え仮にも100MHｚオーバーで動いているCPUとは思えません。・・・とは言え、68kコードをエミュレートしているわけですから、こんなものなのかなぁ、という気もします。グラフィック関係の動作はきびきびしてますし。
それから、わりと簡単にクラッシュします。ソフトリセットは日常茶飯事です。ハードリセットもたまにあります。なんだか、昔PC9801でプログラム組んでたころを思い出してしまいます。これは、こういうものだと思ってかかればたいしたことはないのですが、「OSがシステムを保護して当たり前」な日常を暮らしている者（私です）にとってはちょっとしたカルチャーショックになるでしょう。
とまぁ、こんな感じで開発してみました（だいぶはしょってますけど）。ね、なんとかなるもんでしょ。
Pocket PC への移植と比較すると、Palm OS はちょっとやりにくいプラットフォームだというのが正直な感想です。もちろん”慣れ”の問題もあると思いますが、それだけじゃないです。技術的な機能面では Pocket PC の方がたぶん上です。32ビットでマルチタスク、マルチスレッドでマルチウィンドウシステムですよ。PDAにその機能が必要かどうかという議論はあるでしょうが、これらの機能があった方がアプリケーションソフトを作りやすいのは確かです。それに、APIの整備という点でも Pocket PC の方が上だと思います。上で書いたように、高解像度対応やサンプリングサウンドなどの機能は割と最近になってようやくOSに組み込まれた機能です。もちろんこれからはこれらの機能が標準になっていくわけですから、長い目で見ればたいした問題ではないのかも知れませんが、ちょっと整備が遅すぎたように思えます。その結果ソニーが独自のライブラリを提供するような形になってしまい、結果として今回のようにソフト開発者が困る羽目になっちゃうわけです。もうちょっとスムーズな方法はなかったのでしょうか？ PalmSourceとソニーが共同で標準のライブラリを作ってくれていたらこんなことにはならなかったと思うんですよ。それから、開発環境の整備も Pocket PC の方が上だと思います。なんといっても、Pocket PC 用の統合開発環境はタダで手に入ります。無料なんですよ。無料で eMbedded Visual C++ が使えるんです。無料だからといって機能がしょぼかったりはしません。普通の Visual C++ とほとんど違いはありません。エミュレータの完成度も非常に高く、不具合らしい不具合に遭遇したことはありません（これももちろん無料です）。これはかなり魅力的だと言えるでしょう。それに対して Palm の開発環境はちと骨が折れます。gcc を使えば無料で開発することはできますが、便利に使えるようにするためにはいろんな工夫を自前でこしらえなければいけません。私は軟弱者なのでそれはちょっと勘弁していただきたいです。それと、上で書いたエミュレータの不具合もかなり困りものです。タダで使わせてもらっておいて文句を言うのも気が引けるのですが、なんとかならないものでしょうか？ というわけで、１ソフト開発者としては、Pocket PC の方がやりやすいと思ったりなんかして。
Copyright (C) 2004 Kyohei Ishihata
この文書を書いた人 ： 石畑恭平
この文書への質問等は下記のアドレスにメールしてください。
E-mail : ishihata@amy.hi-ho.ne.jp