Windows CEのフットプリントについて

大きいなどとよく言われている。Windows CEでもスレッドが生成できて若干の通信ができる構成なら数百KBのシステムでも作れる。2KB、4KB？さすがにそれは無理である。今や2716や2732の時代ではない。・・・話が昔過ぎて理解できない!?これは失礼、冗談はさておき、今や携帯電話にでさえメガバイト級のメモリが載っている。因みにWindows CEの場合は64MBもあれば大抵のことはできる。これはPCとは最も違うところだ。その他、ITRONとWindows CEを比較すると、仮想記憶、メモリ保護、カーネルモード/ユーザモード等の大きな違いはいくつかあるが、それはまた別の機会にご紹介したいと思う。
ではなぜ、わざわざ慣れ親しんだITRONではなくWindows CEなのか？なぜ、カーナビの世界でもWindows CEへの移行が進んでいるのか？それは、ITRONにはない別のものがWindows CEには期待できるためだ。ずばりそれは、スケーラビリティだ。Windows CEは、ヘッドレス(GUIのない構成）のゲートウェイ端末からGUIを装備したハンディGPS端末まで、実に様々なシステムを構成することができる。今や組み込みシステムも複雑化する一方、やれGUIだの、やれマルチメディアだのの要求は増える一方だ。カーナビにカラオケなんて話も聞いたことがある。（私はカーナビにカラオケはいらないと思うが。）そうなってくるとWindows CEの威力が発揮されてくる。ネットワークはNT系 Windowsと互換のNDISが動く。勿論Socketも動作する。（Winsockだが）、GUIはWIN32、MFCなどが使える。PCと同じようにDirect Draw, Direct X なども組み込める。COMコンポーネント、Active-Xなども動く。ブラウザもある。メデアプレイヤーを入れれば、動画だって再生できる。あとはメモリーなどリソース次第ということになってくる。
Hiroyuki Shimizu/CodeGaer,Inc.

リアルタイムシステムの考え方について

少し語ってみたいと思う。
最近は減ってきたのだが、Windows CEの導入に躊躇（ちゅうちょ）する理由として（時に、全く相手にされないこともあるが）よく言われていることは「リアルタイム性」である。リタルタイム性？、「なんて日本人はこのことばに弱いことか」と皮肉を言っている場合ではないが、確かにITRONに比べてその性能が・・という向きがあるかも知れない。しかし、ITRONがよりプリミティブに近いものであることを考えると、それは当然といえば当然。ただし、意外や意外、Windows CEはNT系 Windowsとは違って、最初から組み込みシステムを考えてカーネルが再設計されていることもあり、現在のCE5.0、Embedded CE 6.0では殆んどの「リアルタイム性」ことに「ソフトリアルタイムシステム」要求に耐えうるものであると私は確信している。「ソフトリアルタイムシステム」の定義はさまざまのようだが、Windows CEは登場以来、長らくPDAのOSと誤解されていた。「リアルタイム性」あるいは「リアルタイムシステム」とは非常に誤解を生みやすい言葉だ。それは決して素早く動くシステムのことでもなければ、高レスポンスシステムのことでもない。ある外部からの事象に対して、その応答時間が予測できるシステムことである。要は、CPU資源をどう使うかという問題だ。かの名書「リアルタイムシステムの構造化分析」にて、冒頭に面白い逸話が紹介されている。これはリアルタイムシステムについて熱く語るある女性の話だ。私がこれを読んだのはずいぶんと昔のことなので正確でない部分はご容赦頂きたい。かいつまんで紹介すると。彼女はぼやきます。顧客からリアルタイムシステムと散々言われ、うんざりの様子、「彼らはリアルタイムシステムとは何か全く判っていないわ。とにかく素早く動くシステムだと思っているのよ。・・・」こんな感じだったと思う。ある棒（これは鉄製であったかどうかは忘れたが、長さが
１ｍ？いや１フィート？すみませんこれも忘れた。）があり、「この棒の端に核爆弾を取り付けるわ、そしてもう一方の端にテレメトリシステムを取り付けるの。そして、それを砂漠の真ん中に掘った大きな穴の中心に向かって投げ込むのよ。・・・」さらに彼女はまくしたてます。「穴の中心で核爆発が起きるわ。テレメトリシステムは数ミリ秒と生きてはいられないわ。この時、どれだけの爆心地のデータを測定して伝送できるかが勝負なの。・・・リアルタイムシステムとはこういうことなの・・・」という話だ。まぁ話は大げさでどこまで本当かわからないが、ここで考えられることは、リアルタイムシステムは、「ハードリアルタイムシステム」と「ソフトリアルタイムシステム」に分かれるということである。「ハードリアルタイムシステム」とは、マクドネルダグラスのコックピットであったり、BMWのブレーキシステムであったりする訳だ。えっ、どこかで聞いたセリフ、まぁ気にしないで。こうなってくると間違いなくWindows CEどころではない。それは、pSOSであったりVRTX(VxWorks)であったりあるはLynxOSかもしれないが、もはやOSの介在する余地すらないのかも知れない。さて、皆さんの周りにある組み込みシステムとして、「ハードリアルタイムシステム」と呼べるもの、あるいはその必要があるものはいったいどれだけあるだろうか。こう考えると大抵の案件は「ソフトリアルタイムシステム」ではないかと思えてくる。
Hiroyuki Shimizu/CodeGear,Inc.

ITRONとWindows CEの違いについて

語りたいと思う。
まず、Windows CEの同期機構だが、イベントフラグはないものの、イベントオブジェクトという仕組みがある。これはCreateEventによって動的に生成することができる。この仕組みによりイベントによる待ち合わせができる。さらにセマフォ(CreatSemaphore)、ミューテックス(CreateMutex)、クリティカルセクション(InitializeCriticalSection)といったスレッド間同期の仕組みを使うことができる。ITRONに慣れた方にとって唯一困るのがメールボックスかもしれない。NT系 Windowsではメールスロットという仕組みがあるが、Windows CEにはない。しかしこれは、Windows CEの各種同期機構を組み合わせて比較的簡単に実現することができる。実際、私もITRONからWindows CEに移行する開発チームのためにWindows CE版のメールボックス機構を作ったことがある。
さらにもうひとつの大きな違いは、割り込み処理機構だ。ITRONでは割り込みハンドラという実装だろう。皆さんもご存知の通り、割り込みハンドラの実態は割り込みルーチンだ。かつては、この割り込みルーチンに何でもかんでも処理を詰め込む傾向があった。実際、私なども、シリアル通信にてENQ/ACK/NAKのコンテンションプロトコルを埋め込んだものだ。ENQを受信してからACKが出てくるまでの応答が凄いだろう！なんて馬鹿なことで酔いしれていた。今からしてみれば、お恥ずかしい限だ。
ITRONの登場のころから、「割り込みルーチンに処理を詰め込むのは野蛮だよね！」と言った考えあり、とにかく割り込みルーチンの中での割り込み処理は最低限にして、優先度の高いスレッドで多くの処理をさせることが良いとする傾向になってきた。この優先度の高いスレッドのことを「割り込みスレッド」と呼んでいたような気がする。（ITRONの言葉かどうかは定かではないが、もしかしたらiRMXのことかもしれない）しかし、今ではそのような割り込み処理の思想が主流になった。
さて、Windows CEではこの割り込みハンドラに相当するのがISRだ。ISRは通常OAL(OEM Adaptation Layer)の中に組み込まれている。OALとはNT系 Windowsで言うところのHAL(Hardware Abstraction Layer)に相当する部分だが、大きな違いはWindows CEのOALはOEMよって移植され、ユーザにて改版することができることである。勿論このOALの中のISRに割り込み処理を埋め込むこともできるが、Windows CEでは、ドライバのスレッドとして割り込み処理を実装するIST(Interrupt Service Thread)という仕組が用意されている。これは先ほどの話ででてきたITRONの「割り込みスレッド」に相当するものだ。Windows CEでは、割り込みルーチンに多大な処理をさせないという思想が、ISTという仕組みで実現されている。往々にして、このことが、Windows CEでは割り込み処理のオーバヘッドが大きいといった誤解を生んでいるようだが、実際にはエンジニアの判断によってISR、ISTを適切に実装してあげれば、殆どの問題は解決することができる
Hiroyuki Shimizu/CodeGear,Inc.

Windows CEの実行単位とそのスケジューリングについて

語ろう。Windows NT/2000/XPを含むNT系 Windowsでは、タスクという概念はなく、あるのはプロセスとスレッドだ。これは、UNIXやLinuxと共通する概念で、今では最も一般的な考え方だろう。NT系 Windowsは、MS-DOSの歴史も含めて、UNIXのアーキティチャから来たものが多いので、当然といえば当然だろう。スレッドのことを昔のSUN-OSなどではライトウェットプロセスなど呼んでいたこともたったが概念的にはスレッドのはしりだ。
昔から、プロセスとスレッドの関係を説明する判り易い例として、えんどう豆というのがある。別に、いんげん豆でもそら豆でもいいのだが、えんどう豆をちょっと想像してみてもらいたい。さやの中に、豆がいくつか収まっている。このさやにあたる部分がプロセスで、そしてその中の豆がスレッドだ。かつてマルチスレッド登場以前はプロセスが実行の基本単位かつ実態であった。C言語でいえば、main()から始まるMS-DOSの.EXE 形式のプログラムがまさにそれである。だが、MS-DOSはUNIXと違ってマルチプロセスで動作しているわけではないので、厳密にはプロセスと呼ぶのはどうかと思うが、ここではプロセスということにしておこう。さてマルチスレッドが登場すると、１つのプログラムの中に実行の実態が複数存在することになった。main()以外にも実行の実態があるわけで、そうなってくるとmain()＝プロセスというわけにはいかない。そこでちょっと概念を変えて、プロセスは実行の実態ではなく、「入れ物」ということにしようという発想が生まれてくる。こう考えると非常に都合がいい。実行の実態はプロセスではなく、スレッドになる。では、main()から始まるスレッドはプロセスを代表するスレッドだから、これを代表スレッドとしましょう。ということになる。最初のスレッドを代表スレッド、あるいはプライマリースレッドと呼び、２番目のスレッドをセカンダリースレッド・・・と続けて呼ぶこことになった。
かくして、このようなモデルができあがり、UNIXの世界では、POSIXスレッドという標準になった。MS-DOSではかつてVer7.0でマルチタスクになるという噂もあったが、結局それを実現したのはWindows 95になってからだった。ところでWindows CEもこのモデルだ。補足するが、Windows CEのスケジュール基本単位はプロセスではなくスレッドだ。しかも、スレッドには親子関係がない。なので、先ほど説明した代表スレッドとそれに続くスレッドとの実質的な違いはない。.EXEを実行した時、mainを呼び出すスレッドがたまたま代表スレッドだというだけのことだ。
さて、批判もあろうかと思うが、ITRONのタスクに相当するのは、あえていうならばこのスレッドではないかと思う。とすれば、皆さんもご存知の通り、プロセスは、.EXE形式のファイルから起動し、その中にスレッドが存在するわけだから、１つの実行プログラムの中にITRONのタスク環境に似たものが実現できることは安易に想像がつくのではないだろうか。先の、のえんどう豆のさや全体がITRONのタクス環境全体で、豆が個々のタスクというわけだ。Windows CEにおいて、スレッドは CreateThreadによって生成する。勿論プライオリティを設定することもできる。ITRONではCRE_TSKによってタスクを生成し、STA_TSKやACT_TSKで起動するわけだが、これをあえてスレッドで行うならば、CreateThreadをCRETATE_SUSPENDオプションで呼び出し、その後、ResumeThreadを呼び出すとスレッドが走り出す。付け加えておくが、Windows CEは、NT系 Windowsとは異なり、組み込み用途向けにカーネルが再設計されている。Windows CEでは、優先度に基づくプリエンプティブなイベントドリブンでスレッドのスケジュールがなされる。この違いは、ある無限ループするプログラムをWindows XPで動作させた時とWindows CEで動作させた時の動きの違いではっきりと判る。Windows CEでは無限ループより低い優先度のスレッドにCPU時間が割り当てられことは原則としてない。Windows XPはリアルタイムＯＳではないが、Windows CEはリアルタイムＯＳなのだ。
Hiroyuki Shimizu/CodeGear,Inc.