Windowの向こう側・OS/2・編集部から（月刊ASCII 1988年8月号5）

この号の特集は「Windowの向こう側」と題してOS/2とWindows関連の記事だった。

あおり部分をスクラップする。

Windowが開く
Open The Window
　1986年秋に日本で,PC-9801用のMS-WINDOWS Ver.1が登場して以来(アメリカではその前年に登場),いくつかのソフトハウスがWINDOWSのアプリケーション開発をアナウンスしただけで,あまり大きな動きはなかった。それは、そのあとすぐOS/2やWINDOWS Ver.2の発表(1987年春)が予定されていたため、メーカーによっては、MS-WINDOWS Ver.1を飛ばして,WINDOWS Ver.2やOS/2の移植にとりかかった所もあったためである.
　また,当時のアメリカと日本の状況を比べてみると、ハードディスクの装着率や80286CPUのマシンの数などで隔たりがあり,MS-WINDOWSをすんなりと受け入れる体制にはなっていなかった。そのため,WINDOWSを移植するならVer.2から,と考えたメーカーも多かったようだ。
　それから1年たった今年,ウィンドウとそれをとりまく環境はどうなっているのだろうか?

一般ユーザというかエンドユーザーの私たちは全く相手にしていなかった。雑誌で見るだけでショップで動いているところなど見たこともなかった。
以下違うなと思う部分をスクラップする。

向上するCPUパワーで何をすべきか
　現在では,国産メーカー各社の主力マシンは10～12MHzの80286,その上位機種では,16～20MHzの80386が使われている.16bitマシン登場時は,6MHzの8086あるいは8088であり、当時と比べてクロック比で2～3倍以上,CPUの処理能力では4倍以上にもなっている.
　さらに,メモリのサイクルタイムが高速化し,その容量も大きくなるにつれて,パーソナルコンピュータのシステムとしての処理速度も向上した.従来,外部記憶装置を使いプログラムをいくつかに分割しオーバーレイとして実現しなければならなかったプログラムも,すべてメモリに置けるようになったのである.
　これらに加えて,描画デバイスや高速な周辺装置などの登場も,システムを高速化している.ハードディスクを導入しただけで,プログラムの起動や処理時間が速くなった,というような部分である.
　ハードウェアの進歩により,負担だったグラフィック処理も比較的高速に行え,文字をグラフィックで表示してもテキストVRAMに表示した場合とあまりかわらない速度で処理できるようになった.グラフィック表示にすると,テキストVRAMで行う場合に比べ表示位置やフォントなど、自由度は大きい。特に最近のワープロソフトでは,画面イメージを印刷イメ-ジに近づけるようにしているため、このような処理が必要となる.
　以前のハードウェアであれば,こうした処理は,大変な負担だった.グラフィック処理中心のアプリケーションを動かすと「画面がズルズル」と動き,お世辞にも「快適」とはいえない,というのがユーザーの印象であった.しかし,10MHzの80286なら実用的な速度で,80386ともなると,グラフィックであることさえ意識させない速度となる.
　ウィンドウ環境との関連でいえば,そのオーバーヘッドが気にならない程度になってきた.従来は、アプリケーション本来の作業をするだけで,CPUは手いっぱいで,これに更にグラフィック処理を行わせていたため、遅かったのである.現在では,こうしたアプリケーション本来の処理に加えて,グラフィック処理を行っても,なんら問題のない状態なのである.

いやいや嘘だから。8086では使い物にならない位遅いので日本はテキストVRAMを考案し使えるようにした。テキストVRAMを使っていいのなら8bit機のX1-turboだって98のワープロ並みに使えるものだった。MS-DOSのプログラミング解説本はMS-DOSをバイパスして直接テキストVRAMを扱うテクニック等が書かれていた。グラフィックRAMなら当然物理アドレスに直接データを書きこんだりEGCを使ってプログラムを書かねばくそ遅いプログラムになっていた。MS-DOSのアプリがやっと仕事に使えるようなる、使い物になったと実感したのは80386を積んだPC-9801RAだった。その後発売された安価なPC-9801RXが職場に導入されたが、PC-9801RAが空いていないときしょうがなく使っていた程80386と80286の差があった。「向上するCPUパワーで何をすべきか」だと。今まで使っていたMS-DOSで快適に仕事をすることだ。何が悲しくてグラフィックなどを使ってエンドユーザがストレスを溜めねばならないのだ。この記事を読んで昔のストレスを溜める遅いマシンで仕事をしたことを思い出した。

すべてのアプリケーションに同じものがある
　いままでのハードウェアの進歩は,主としてソフトウェア側からの要請の結果である.計算やグラフィックス表示といった処理を実用時間内に処理するには,高速なシステムが要求されたのである.
　BASIC中心の利用形態であったときには,まずグラフィックスの表示速度に要求が集中した.一部のマシンではCPUの負担を軽減するために描画デバイスを装備したり,複数プレーンに同時に書き込みが行えるようなハードウェアを装備していた.しかし,CPUの能力が上がるにつれ,CPUが直接描画したほうが高速で,また細かい操作もやりやすいとなると,高速な表示を望むアプリケーションは、描画ハードウェアを使わずそれ自身が表示を行うようになった.現在のアプリケーションのほとんどは,多かれ少なかれ、このようなグラフィック描画ルーチンを抱え込んでいる.さらにテキストVRAMに関しては,BIOSやOSのファンクションコールを使っているものは希で,ほとんどのアプリケーションにそのためのルーチンが組み込まれている.
　実は,我々のハードディスクの中には,同じようなルーチンが山のように詰まっているのである.アプリケーションによっては,処理本来の部分よりグラフィック処理のルーチンのほうが多いものさえあるのだ。
　作る側からいえば、同じようなものを何回も作る手間があり,使う側から見れば,同じようなルーチンがメモリやディスクを占有しているのである.
　こうした技術的な問題とは別に,パーソナルコンピュータが普及するにつれ,それらはどんどんオフィスに進出し,誰でもが使えるように,ヘルプシステムやわかりやすい表示をする必要が生じた.
　それらに加えて,以前から使い続けていたユーザーは,さらに高度な機能を要求するようになる.画面イメージを印刷イメージに近付けたり,コマンドを増やす,強化する,あるいは一度に扱うデータ量やファイル数を増やす,といった要求である.このため、アプリケーションはどんどん大きくなっていくのである.
　こうした問題を解決するには,アプリケーションから共通部分である表示,ユーザーインターフェイス部分をモジュールとして独立させ,それを中心に各機能モジュール(プログラム)と連動させるという方式を取ればよい(図2).
　こうしたモジュールがウィンドウシステムである.このシステムは個々の機能モジュールからは,画面表示や相互の連係を行うOSの側に属したモジュールのように見える.
　そのためアプリケーション開発者は,画面表示のためのファンクションコールを行えばよい.各モジュールは,それぞれの機能のみを実現すればよく、画面制御や他の機能との関係をそれほど考慮しなくてすむのである.

ここは同意できる部分だ。「一部のマシンではCPUの負担を軽減するために描画デバイスを装備したり,複数プレーンに同時に書き込みが行えるようなハードウェアを装備していた.」まさにPC-9801がそれだ。だから使える機械になった。ここに書いてあることは各ソフト会社が対応してきた。各社のライブラリの出来の良い悪いがそのままアプリの性能になった。まあ、しいていえば欲しいのはオーバーラップウインドウに対応したグラフィック描画ルーチンだった。高速化のためにはもちろん各機種専用になるのは仕方がない。

CPUのパワーは余っている
　アプリケーションの実行速度は,ハードウェアの進歩により確かに速くなった.しかし、アプリケーションのうち,CPUの負荷が大きい部分はそのごく一部である.ワープロソフトでいえば,画面表示の部分などは,かなりCPUの速度に影響される.しかし,文字入力や削除などの部分は,それほど負担にはなっていない.さらに,キー入力やファイルの入出力については、CPUの速度にほとんど影響されない。ほとんどの場合,CPUの能力はまだ,余っているのである.
　大型機のバッチ処理のような形態や,純粋な数値計算のみならば,CPUを待たせることなく働かせることが可能だが,人間が直接操作するパソコンでは,こうしたCPUの「遊び時間」をなくすことはできないのである.
　CPUの「遊び時間」を有効に使う方法の1つは「マルチタスク」である.1つのプログラムを見ると,かならず何かの事象が終わるまで待つという部分が存在する.そのときに別のプログラムを動かすという発想である.このマルチタスクは、前述のアプリケーション間のインターフェイスとも密接に結びつくもし同時にアプリケーションを動かすことができなければ,それらの間のインターフェイスもあまり役にたたないのである.
　逆にOSがマルチタスクだった場合,複数のタスクからの出力をどう管理するべきだろうか?すべてのタスクが同じ画面に出力したのでは,何の出力だか分からなくなってしまう。そこで画面出力するタスクにそれぞれウィンドウを割り当てれば,出力を互いに分離して管理できるようになる.
　複数のプログラムを同時に動かすには、なんらかの仕組みが必要になる。1つはOS自体をマルチタスク化することである.OS/2(そしてPM)はまさにその方向を狙ったものであり,MacintoshのOSも制限付きではあるが,このような機能を最初から実現していた.そして,もう1つの方法は、OSとアプリケーションの間にマルチタスク化のための機構を導入する方法である.MS-WINDOWSは,こうした機構の1つである(図5).
　WINDOWSの場合,MS-DOSという限られた世界の中で,マルチタスクと疑似的な仮想記憶を実現している.
　ウィンドウシステムには,マルチタスクシステムを効率よく使うためのユーザーインターフェイスとしての側面もある.ウィンドウシステムとマルチタスクは表裏一体の関係にあるのだ.

何を言っているのか。全然違う。CPUの遊び時間をなくしたいだと。逆だ逆。人間の遊び時間をなくすべきだったのだ。パソコンなのだ。どうせ、一人一台しか使えないのだからCPUが遊んでいても何ら問題はないのだ。律速段階は人間なのだ。パソコンが空いていなければ他の仕事をして使用順番を待っていた。マルチタスクになったってパソコンを使用する業務時間は短縮されない。

マルチタスクの実現
　WINDOWSで実現されているマルチタスクは、OS/2などのマルチタスクとは多少違っている.まず,大きな違いは,タイマ割り込みによる強制的なタスク切り替えが起こらないことだ.
　WINDOWSでは,タスクの切り替えは,MS-DOSでいうファンクションコールの発行時にのみ起こる.つまり,アプリケーションが内部で処理を続けている間は,他のアプリケーションは停止したままになる(図3).通常のアプリケーションは,キー入力やマウスの移動,ボタンの押下といった事象の発生を待ち(これも事象が発生するまで待つというファンクションコールで行う),それをもとに動作するといった形態となり,それらの事象が起こるまで処理を先に進められないので,このような方式でもそれほど問題はない.
　CPUの速度が遅いと,このファンクションコールを発行する時間間隔が長くなり,単位時間内にタスクが切り替わる回数が少なくなる.そうすると、処理が止まっているのが目に見えるようになってしまう。このため6～8MHzの8086などでは,かなり遅く見えたのである.だが,CPUが80286や80386の場合には,実用上問題はない.

恐ろしいことを書いている。ファンクションコールがなければタスクが切り替わらないだと。重たい処理をしているとき、配列を走査して沢山計算して、結果をメモリに書き込むような処理ではファンクションコールなどしない。これではフリーズしたように思われても仕方がないのではないか。これでは使えないと思う。このときのWindowsはこんなものだったのか。酷い。「このため6～8MHzの8086などでは,かなり遅く見えた」かなりとはどのくらいなのか。リセットボタンを押したくなる時間ではないのか。8086は使えないCPUだった。思い出すのはPC-9801Fでマルチプランを触らせてもらったときのこと。普通にカーソルがオーバーランした。8bit機にも劣る性能だと思った。こんな製品をよく売っていたものだとマイクロソフトを嫌いになった一因だった。16bit機のソフトは8bit機を使うときとは違い、キーボードをゆっくり押す、押したら離す、反応を確認したらまた押すというように恐る恐る使わなければならない機械だと思った。
　Windowsはi486のWindows95になってやっと使えるものになったと思っている。Windows 3を使ったが良く落ちた。だが、PageMakerなどWindowsじゃなければ使えないアプリがあったのでこまめにファイルをセーブしてドキドキしながら使った。もちろんMS-DOSで動くアプリがあればWindows版なんて導入しなかった。

Windowsの開発環境についてスクラップする。



この号の「OS/2がやってきた」は特にスクラップしたい内容は無かった。


編集部からもウィンドウについてだった。

ウィンドウ環境への期待
　先日,大学時代の仲間の集まりがあった.「マイクロコンピュータを作る会」というサーークルの同期の集まりで,メンバーは7人.12年前にモトローラの6800を使ってワンボードマイコンを作ることから活動を始めたサークル仲間で,現在でも全員がコンピュータ関連の仕事をしている.集まれば,もちろんコンピュータの話題が出る.
　その席で一つだけ驚いたことがあった.メンバー7人のうち3人がMacintoshユーザーだったのだが,これは,6800からこの世界に入った人間の集まりだから,それなりに納得がいくそれより驚いたのは、Macのどこに良さを見いだすかだ.
　以前であれば,Toolboxがどうだとかいったことが話題の中心になるはずだった.それが,マン・マシン・インターフェイスに賛辞は集中したのだ「いまさら,いろいろなコマンドを覚える気はしない.プルダウン・メニューでコマンドを選べるのはいいね」などという意見が圧倒的だったのだ。確かに,コンピュータの仕事をしているとはいえ,普段は大型計算機を相手にしている人間も多い.30過ぎて少し疲れが出ているのかなとも思えるが,それでも,予備知識なしに,すぐに使えることに良さを見いだすのは、悪くないだろう.12年前,我々がマイコンを触り始めた頃,それで遊ぶためには,さまざまな事柄を覚える必要があった.また,たくさんの事柄を記憶している人間が偉いかのような時代でもあった。そうした頃に活躍したホビーストが,いま,マン・マシン・インターフェイスにこだわっていることに驚いたのである.
　今月号で特集したウィンドウ環境には,記事中にもあるように,さまざまな要素がある.とはいえ,その大きな目的の一つにマン・マシン・インターフェイスの向上があることは間違いない.そして僕自身,その普及がパーソナルコンピュータを従来になく,多くの人に親しまれるものへと変身させてくれるのではないかと,期待している.

(土田米一)

これは納得できた。多くの人に親しまれるようになったのはWindows 95からだった。これから7年後だ。