「端末」と言う言い回しはそもそも難しい。
実は「端末」とは、フツーの日本語では「末端」の事なんだよ(笑)。漢字の配置が逆だ(笑)。
いや、それは英語での「terminal」の訳語だ。ターミナル、っつーと何かカッコいい響きがあるけど、ホンマ「端っこにある」とか「終端の」って意味なんだ。
列車の駅で「終着駅」を「ターミナル」と呼称するのはそのせいだ。あらゆる路線はそこに集まってそれ以上に路線はない。変わって随分と経つけど、かつての上野駅は以東/以北の列車の終着点で、それ以上先に進めなかった。また、東京駅は以西の路線のターミナルだった。これらで路線は分断されてたわけだよな。
また、空気抵抗がある前提で物体を落下させるとある速度に到達してそれ以上速度が増えない。その最終速度も英語では「terminal velocity」と呼ぶ。「終端」速度そのもん、だよな。
コンピュータで言う端末、ってのはそもそもかつてのモデルが「中央に演算処理用システムがあり」、それにモニタとキーボードが複数繋がってた事に由来する。
つまり、このモデルで見ると、モニタ/キーボードはメインフレーム(コンピュータ本体)に対しての「終端」であり、「その先はない」わけだ。
そして言い換えると、「ターミナル」ってのは「終端である状態」の事であって、別に「機能」でも何でもないんだよね(笑)。
しかし、「使ってるうちに」その意味がビミョーに変わっていく、ってのも良くあるわけだ。
繰り返すが、コンピュータ用語の「端末」とは元々、上の図のような「中央に演算用システムがあり」それに複数モニタとキーボードが繋がってた事に由来する。
言い換えると、この当時の「端末」ってのは中央の処理装置に対する「キーボードから打ち込んだ」データの転送、そして中央から送られて来た情報を「受信して表示する」為だけのマシンであって、見た目はともかくとして、基本的に端末そのものに「計算能力」があったわけじゃないんだよな。とにかく人間に対する「インターフェース」を提供してただけであって、それ自体が「計算機」だったわけじゃないんだ。
DEC社の名作端末、と言われるVT100
当然1970年代に開発されたUNIXもこういう背景で登場している。目的は「端末と中央演算処理装置間のやり取り」が中心になっていて、それ以外は「色々と面倒くさいんで」端折ってたような想定になってたんだ。例えばリターンキーを叩くと「入力したデータを中央演算処理装置に転送する」合図になってるが、aとかbとかのキーと「何らかの命令を直接結ぶ」ような事にはなっていない。また、そもそもが「ショボい中古ミニコン上で開発された」事もあって、端末上に何らかのグラフィックスを表示する、なんつー事も考えてなかった。
ハッキリ言っちゃって、以前紹介したPLATOに比べるとUNIXは全然ショボい前提だったんだ(※1)。
余談だけど、C言語が登場して標準入出力(stdio.h)って概念が出てきたんだけど、ここで言う標準とは言っちゃえば標準じゃないんだよ(笑)。色んな端末であり得るキーの「どいつもこれらキーは入ってるだろ」前提のミニマリスティックなサブセットを意味してたんだ。そして、やはり特定のキーと動作を結びつける事はできない。例えばカーソルキーが存在するキーボードで矢印を叩くと、端末に表示されたキャラクタが動く、とかそういったプログラムは書けないんだ。
なお、現在はISOの方でキーボードにはどんなキーを持つべきか、と言う事が定義されている。入力については、言い換えると、現時点では本物の標準入力がある、って事なんだけど、プログラミング言語の「入力機構」にはいまだ反映されてない、んだ。個人的にはいい加減、この辺一致すればいいのに、とは思ってる(※2)。
さて、1977年に初のオールインワンパソコン、Apple IIが登場する。
Apple IIを起動すると次のような画面が立ち上がるわけだ。
これは果たして端末、だろうか。
古典的なコンピュータ・システム的用語で見ると、これは端末じゃない。本体が遠く離れたトコにあるわけじゃないし、別に管理者がいるわけでもない。すべては貴方の管理下にあって貴方しか使えず、貴方の好きなようにプログラム出来る。まさしくパーソナルコンピュータだったんだ。すべてがunder controlなわけだ。
Apple IIの凄いトコは「機械のすべてをユーザーが好きなように使える」ようにした辺りで、この発想は明らかに後続の機械に影響を与えてる。そして、これは開発者であるスティーヴ・ウォズニアックの慧眼だろう。
Apple II のBASICにはGR(グラフィック)モードと言うものがあって、プロンプトにGRと打って【Enter】を打つ事でそのモードへと入れる(※3)。
Apple II GRモード
上では左端上部、右端上部、左端下部のそれぞれに緑、緑、オレンジ、と色を置いていってる。
これは次のプロンプトへの入力で行われている。
COLOR=12PLOT 0,0PLOT 39,0COLOR=9PLOT 0,39
色番号12は緑、9はオレンジで、COLORと言う変数にその数を代入する事で「画面に置く」色を決定する。Apple IIでは最大16色しか使えない。
PLOTで二次元座標にドットを置いていくわけだ。
上の画像を見て
随分とデカいピクセルやな。しかも横に長いしwww
とか思うかもしんない(笑)。
そう、Apple IIでは、色数を多く使おうとすると、ピクセル数は40x40しか使えない。つまり、たかが1,600ピクセルしか扱えないんだ。
しかし、それでも、プログラマの「思い通り」にピクセルを置く事が出来る。ある意味、史上初の「ドット絵」が描けた、っちゅーこっちゃ。そして同時に、大学や企業に置いてた殆どのミニコンで「得られなかった」事が出来るマシン、と相成ってた。
そして、Apple IIにはもう一つ特徴があった。実はApple IIの「モニタ表示用」のメモリはモニタの二倍、量があったんだ。つまり、実は「二画面分」搭載してた。
その使いみちは、一画面目を表示してる間に二画面目を用意しておき、二画面目を表示してる間に一画面目を書き換える、と。つまりアニメーションする事を前提に設計されてたんだな(※4)。
スティーヴ・ウォズニアックは明らかにApple IIを「プログラミング可能なゲーム機」としてデザインしている(※5)。そもそもそれまでは、PLATOのような機械を除くと、メインフレーム上では、BASICを使っても今我々が想像するような「画面全部がグラフィックまみれの」ゲームになってなかった。一方、Apple IIではBASICで「直接モニタ上のピクセルを操作出来る」ようにした為、ある意味この時点で、一般的なメインフレームに出来ないことをやってのけている・・・演算速度が敵わないにせよ、だ。
いずれにせよ、元々Apple IIって製品はそんなにシリアスな製品じゃなかったんだよ(笑)。後に初の表計算ソフト、VisiCalcの登場でビジネスでも通用するマシンだ、と証明されたが(※6)、そもそもスティーヴ・ウォズニアックは、そんな「ソフトウェアビジネス」、つまり「ソフトウェアを売り」、「ソフトウェアを買う」と言うような事がApple IIで生じるとは夢にも思ってなかったらしい。
ウォズニアックが夢見てたのは、Apple IIユーザーの全てがプログラミングを楽しみ、カラフルなゲームを書き、仲間内でそれを見せあって遊ぶ世界だったんだ。
その夢は実現しなかったけど、この「BASICでモニタを直接制御する」と言うようなアイディアは後発のPCにかなり影響を与える事となる。
NEC PC-9801での内蔵ROM BASICでの描画例。基本的には色を指定して、座標を指定してカラーを置いていく、と言う方式は、実のトコ、数学系のグラフプロット用ソフトウェア、gnuplotなんかのインターフェースに近い。結果、ある意味、当時のグラフィカルなゲームはgnuplotで組んでたようなモンだ。
なお、1980年代のパソコンでは、BASICは今で言うトコのBIOSの役目を果たしていた。
例えば、上の画像はPC-9801(のエミュレータ)での例だ。もう内蔵BASICが「直接」モニタのピクセル上に「色を置ける」ように設計されていて、要はPC-9801用のプログラミング言語も直接ハードウェアを操作出来るような設計にする事が可能だった。
PC-9801は640x400がモニタ一画面分のピクセル数だ。つまり総数は256,000個。Apple IIの160倍のピクセル数をプログラマがコントロール出来る。まぁ、その数は大変な量、ってば大変なんだけど、Apple IIが登場してから数年で、日本では機能的にはApple IIを遥かに凌駕するようなパソコンが登場した、って事だ(※7)。
80年代から90年代初頭にかけて、MS-DOSと言うOSが支配的になってたが、原則これは「ユーザーのコンピュータの描画機構へのアクセス」を妨げる事が無かった。ユーザーは「直接」モニタへの描画を弄れたんだよな。この時代のMS-DOSパソコンのモニタは文字通り「一枚絵の為のキャンバス」だったんだ。
PC-98シリーズの末期、PC-9821のまたもや末期に現れたゲーム「Night Slave」での画面。同時発色数は256色へと増えているが、モニタ丸ごと使って一枚絵を描く、と言う技術的手法は変わらない。ドット絵と考えると、Apple IIから考えると殆ど最高レベルに達している(笑)。
さて、MS-DOS系マシンは根本的には「ユーザーの入出力に制限を持たせない」設計になってて、それは世界初のオールインパソコン、Apple IIからの「伝統」だった。
一方、UNIXはどうだったのか、ってぇと、上にも書いた通り、いわゆる「端末挙動」、つまり、入力してEnter(あるいはReturn)を叩くと文字列がスクロールして反応が返ってくる、ってだけのシステムだった。画像が表示出来たり、とかそういう事は全く出来ないシステムだったんだよ。そしてそういう「システム」前提でC言語の標準入出力、ってのが定義されていた。
UNIXはショボい、ってのは事実なんだけど、致し方ない背景もあったんだ。Apple IIだとAppleって会社が自由に入出力を定義出来た。NECもNECの作るマシンで自由に入出力を定義出来た。富士通は富士通の、シャープはシャープの、って事だよな。
そう、入出力「機構」に関して言うと、突き詰めれば各社のマシンは互換性なんぞねぇんだ。
従って、ユーザーはある会社のマシンを使う際には自由に出来る、んだけど、一方、NECのマシンで作ったプログラムを富士通に持っていくのはかなり難しかったんだ。「プログラミング言語の部分」じゃない。画像とか入力機構の部分だ(※8)。
一方、UNIXは違う。こいつは特定のマシンをターゲットにしていない。と言うか特定のプラットフォームを持たない。結果、各社固有の入出力機構に頼る、と言うOSにはなれなかったんだ。言い換えると、UNIXは各社のコンピュータを最大公約数的にしか活かせないOSだったんだ。
しかし、さすがに80年代に入ると、それはそれでプログラミングに面白みが出ない、って状態になっていた。パソコンなら「自由にプログラム」出来るのに、UNIXだとそこまでイカン、と。
断っておくけど「UNIXが」だ。メインフレーム全般がそうだったのか、ってぇとそれは違う。つまり、パソコンと同じく、メインフレームでも製造会社が添付してくれるOSを扱う限りそういう不具合は生じない。言い換えると、例えばHP(ヒューレッドパッカード)みたいな製造会社が作るOSならマシンの性能を絞り切るようなプログラミングを許す、んだ。あくまでUNIXが最大公約数的、なんだ(それでもコンピューティングの主な目的は遂げるわけだが)。
そこで、1978年にcursesと言うライブラリが作られる(※9)。
平たく言うとcursesは、UNIXより「下のレイヤー」の入力制御をラッピングしたモノで、その「入力制御」は、考えうる各マシンの「仕様」を全部並べる、と言ったモノだ。その「各仕様」を共通の関数でラッピングして上のレイヤーに伝えるような構造になってんだな。
これで、「各キー」とプログラミングした「関数」を結びつけて、キャラクタが端末上を自由に動き回れるようにした。スクロールなしで、だ。
これで「文字」とは言えど、自由にモニタ上を走り回るようなゲームを書けるようになったわけだ。
そしてApple Macintoshが登場した1984年同年、UNIXではいきなりGUIを意識したグラフィックシステムが登場する。X Windowがそれだ。
X Window System。MITによる開発だった。今でもUNIXや各LinuxディストリビューションのGUIの屋台骨となっている。
X WindowはMITが作った割にはUNIXの思想と相性が良かった。これも「特定の機械」対象じゃなく、主だったトコの機械の仕様に対して「共通のインターフェース」でラッピングするように書かれてたんだよな。言い換えると従来のパソコンみてぇな「ユーザーが直接ハードウェアを触って画像を操作出来る」ようには出来ていない。
余談だけど、このX WindowはSun Microsystemsみたいな分散型ワークステーションメーカーには大ウケだったんだ。一方、旧来のメインフレームを使った「中央演算処理装置」が全計算を引き受けるようなモデルでは嫌われていた(笑)。90年代中頃まで、X WindowとEmacsは「メモリを食いつぶす」システムだ、ってぇんで敬遠されてたんだよ(笑)。まぁ、一台のミニコンを数人で共有する、と言うような「マルチユーザー」のシステムだとイマイチ美味しくないんだよな(笑)。結果、X Windowが本当の意味でユーザーに浸透するのは、Linuxが登場して、各自の「パーソナルコンピュータ」にインストールして全体リソースを気にしなくて良くなった、90年代後半から、なんだわ。
さて、「画像処理」に関して言うと、目的のせいもあるんだけど(ハッキリ言っちゃうと「ゲーム」だ・笑)、ある程度パーソナルコンピュータの方がCPUの性能はさておき、市場をリードしてた事が分かる。
一方、現代だと、LinuxのようなUNIX互換のOSが持ってる「端末」に比べるとWindowsのDOS窓(コマンドプロンプト)が、あまりに「使えない」っつーか、往年のPCのプログラミングみたいな事が「出来ない」んで、一体これはどういう事なんだ、的な話になってくる。言わば「DOS窓はUNIXの端末に比べると非力だ」、と。
いわゆる「DOS窓」。正式名称は「コマンドプロンプト」。
しかし、実の事を言うと、「DOS窓」とUNIX/Linuxの「端末」は目的が違う。言っちゃえば全く別のジャンルのソフトウェアなんだ。
現在のUNIX/Linuxの「端末」の正式名称は「端末エミュレータ」と言う。つまり、Shellもクソも関係なく、実は目指してるトコは往年の、上で紹介したVT100のようなハードウェアのエミュレータを意図してるんだ。そう、まさしく文字通りエミュレータなんだよ。仮想マシンなんだ。
つまり、現実に過去あった端末専用機が出来る事はすべて出来るように設計されている。
一方、DOS窓は違うんだ。あくまでMS-DOSをコマンドで実行するためのソフトウェアだ。つまり、往年のMS-DOS機、要は基本的にIBM-PCを再現する為のソフトウェアじゃない。
いや、良く「DOS窓はUNIX系の端末に比べて非力で・・・」とあたかもマイクロソフトの技術力が無いような言い回しが多用されるけど、それは事実じゃないと思う。これは単なる失策だ。要はテクニカルな問題じゃなくってプランニングの失敗だと思う。
かつ、結構デカい失策だとは思う。
Windowsと言うOSに付属すべきは、かつてのIBM-PC(MS-DOS機)の完璧なエミュレータであるべき、だったんだ。
DOS窓ってのはかつてのMS-DOSが走ってた「パソコン」の旨味を全部捨てたようなモンなんだよ(笑)。Windows 95の登場によって、それまでの「パソコン」の強みがみんな消え去ってしまった。要は黒画面に自由に色を置いてプログラムする、と言うような事が出来なくなって、ある意味「ショボい時代の」UNIXみたいな状態になってしまっている。
逆行だ。退行だ。
そして、MS-DOS時代に築き上げた「ゲームプログラミング」のノウハウなんかも皆捨ててしまったようになったんだ。そこには、かつて存在した「ホビーパソコンでのプログラミング」と言うモノが全くない。
言い換えると、Windowsになってから、かつての「ホビイストによるプログラミング」を全部追い出したように見える。あるいは、もっとプロ向けで、C++を使いこなしてるような人にしかWindowsでプログラミングさせたくない、って意図があったかもしんない。
または、MS-DOSからWindowsへ移行するにあたって、「既存のソフトウェアを全部買い替えて」ほしかったのかもしんない。DOS窓で自由に描画出来ない、って事はかつてのDOSゲーはWindowsでは全く走らない、ってこった。技術的には十分可能であったにも関わらず、マイクロソフトは恐らくそういう「商売上の決定」を優先させたんだよ。
結果何が起きたのか、っつーと「Windowsでプログラミングするのはアホらしい」的なムードだ。いやだから失策、っつったろ。
DOS窓でかつてのようなプログラミングが可能だとしても、別にマルチウィンドウを邪魔するこたぁねぇし、むしろ余計な事は全部DOS窓に任せられるのにそれをせんかったんだよな～。どうも「技術的な意図」とは全く違った何かを感じる。
これ、ホンマ極めて厄介な問題をはらんでるんだ。要は「往年のホビープログラム」的なモノを書けない。
例えば、WindowsでもRogueはある。
Rogue Clone II for Win32
これ、DOS窓で走ってるように見えるんだけど見かけだけ、なんだ。
実際はれっきとしたGUIアプリとして書かれている。DOS窓のように見えるだけのウィンドウなんだ。
つまり、端末っぽく見えるブツは実際は自作、だ。WindowsでRogueのようなゲームを書こうとすれば自分で端末っぽいブツまで作らんとアカンって事になる。
ハッキリ言えばプログラミングの難易度はここでメチャクチャ上がり、昔なら比較的簡単に書けたソフトがWindows環境でのプログラミングだとメチャクチャ敷居が高くてムズい。
それが今のWindowsプログラミングの弱点なんだ。
元々、Microsoftの失策さえ無ければ、往年のMS-DOSゲームでさえそのままWindowsで実行出来てただろう。
出来ないから、こそ、有志が集ってDOSBOXなる昔のIBM-PC系MS-DOSのエミュレータを作らざるを得なかったわけだ(※10)。
DOSBOX(※11)
MS-DOSが動くOS(Windows)上でMS-DOS機のエミュレーション、とかちょっと考えてみれば如何に馬鹿臭い状況になってるか分かるだろう(笑)。
全てMicrosoftの失策のせい、だ。
末期のMS-DOS機(IBM-PCコンパチ機)は256色同時発色、まで進歩してて、解像度はVGAで640x480、SVGAで1024x768の解像度にまでなってる・・・仮にそういうスペックの、キチンとした「エミュレータ」がWindowsに搭載されていたら、僕らが見るプログラミングにおける世界は随分と様相が違ってた事だろう・・・プロやエキスパートはC++でのGUIプログラミング、端末エミュレータではCやBASICによる往年のホビーパソコンでのプログラミング、と棲み分けられてたのではないか。
Windowsのコマンドプロンプトがおかしな戦略で歪んできた一方、元々ハードウェアエミュレータのつもりだったUNIX/Linuxの端末エミュレータはかつての実機より性能が上がっていった。
具体的には、かつての実機は黒画面に緑の字、とかワケが分からん配色だったのに、今だと「当時全く無かった」カラフルさまで入手している。
その辺がソフトウェアの強みで、端末上に「写真」まで載せられるくらいにUNIX/Linuxの端末エミュレータは進化するんだよ。
例えば、Chafaなんてソフトウェアを使えば次のような事が出来るトコまで来てる。
例によってAV女優、河北彩伽の写真だが、たしかに端末エミュレータ上に写真が映ってる。
いや、別にAV女優だからモザイクかけたようになってるわけじゃなくって、取り敢えず現時点ではこれが限界なんだけど、って意味なんだ。端末は文字指向で行指向なんで、ピクセル毎にコントロールする事を念頭に置いてない。あくまで「一文字分」を単位としてる。
結果、画像を表示しようとすると、どうしても「文字単位の」画像にならざるを得なく、「豪華なApple IIモニタ画像」みてぇになっちゃうんだよ(笑)。ただし、使える色彩数はかつてのApple IIやIBM-PCの比じゃない。色数は自在に近いんで、結果モザイクみたいになるわけ。
しかしながら見たように、描画が出来ないわけじゃない。DOS窓が「かつてのパソコンなら出来てた事」を切り捨てたのに、UNIX/Linux系の端末エミュレータは着々と進歩してるんだ。言っちゃえば「かつてのホビーパソコンの領域」へと進化している。
あとは、一体誰が「ピクセル単位の」端末エミュレータを開発するのを思いつくのか、だ。皆今は端末と言えばどうしても「文字だらけの」としか考えていない。しかし、いつ誰が往年のApple IIのような「GR(グラフィック)モード」を備えた端末を思いつくのか(※12)。思いついて実装出来たら、そのOSはかつてのホビーパソコンのような楽しい「おもちゃ」と化すんじゃないか、って思う。
WindowsでもLinuxでも構わない。そろそろ「マジメなOSの」フリを止めて、そういう「おもちゃ」を開発して装備して欲しいトコだ。
かつては、演算速度が無くても、グラフィック操作を簡単に提供してた事がホビーパソコンが殆どのメインフレームに勝ってたトコロだった。しかし今はWindowsはその手の利便性を捨て、UNIX系OSの端末エミュレータの自由度はWindowsのDOS窓/PowerShellの「機能」を凌駕してる。UNIX系OSの端末エミュレータの方が往年のホビーパソコンの能力に極めて近くなってるんだ。逆転現象だ。
UNIX系OSで生まれたプログラミング言語なら、大体のトコ、cursesをラップしたライブラリを提供してるか、あるいはそのテの外部ライブラリが見つかるだろう。それを使えばかなり自由な「端末エミュレータ上の」ゲームを書ける筈だ。
難点は、結局WindowsのDOS窓/PowerShellは古典的なUNIXの端末に事実上近いんで、ポータビリティを考えるとそのテのプログラムは同じUNIXのiMacには持って行けてもWindowsには持っていけない、って事だ。
結果、どういうわけか、使うライブラリさえ間違えなければGUIのソフトの方が全プラットフォーム間で行き来はしやすくなってる、ってのが現実なんだ。
そしてポータブルなCLIのゲームは、Windowsを考えると書くのが難しくなっている。
繰り返すが、現在ではどういうわけかGUIのブツの方が移植は簡単になってるんだよ(※13)。
※1: 繰り返すが、マジでPLATOはオーパーツのような製品だ。1960年代に作られたクセに、モノクロームでありながら高解像度グラフィック端末を備えてて、それを操るようなプログラミング言語(TUTOR)を持ってて、後のパソコンで可能になった、任意のキーに対して反応するようなプログラムが書けて、なおかつネットワークを構築してる・・・まさしく後のPCにおける「ホビイスト」を生み出した、歴史上極めて重要なマシンだ。
※2: JISキーボードよりASCIIキーボードの方がシンプルで美しい、等と言うフレームには加わらない事。ASCIIキーボードはISO規格を結果無視している。実はJISキーボードは基本的に「世界標準」のISOレイアウトに則って決められているんだ。
※3: これはLinux用Apple IIエミュレータ、LinAppleを用いて実験している。
※4: PythonのPyGameも実は似たような仕組みで設計されている。
※5: 同年、初のカートリッジ式ゲーム機、ATARI 2600が発表される。Apple IIもATARI 2600も同じCPU、MOS 6502を採用している(厳密に言うとATARI 2600は廉価版であるMOS 6507採用だが)。
1975年に発表されたこのCPUは、インテル製チップやモトローラ製チップに比べると破格の安値で、北米で「パーソナルコンピュータ」や「ゲーム機」と言う製品とその市場を作り出すには極めて重要なCPUだった、と言う事が出来る。
北米のパソコン/ゲーム機の黎明期を彩ったCPUだが、一方、IBMがIBM-PC(後のWindows機の原型)開発の際にインテル製CPUを採用したせいで、その後のPC = インテル製CPU、と言う路線が確固としたモノになってしまった。
※6: アメリカのサラリーマンは日本みたいな源泉徴収があるわけではなく、確定申告も自ら行わないとならないらしい。従って給与から税金を計算する為にApple II + VisiCalcはバカ売れした、と言うような話がある。確定申告がApple IIの普及を助けたんだ(笑)。
※7: 実際、NEC PC-9801は登場時、世界的に見ると、高精度で高度なグラフィックス能力を持ったマシンとして登場してる。もちろんApple IIと違って「マジメなビジネス機」として生まれたが(NECではPC-6xxxやPC-8xxxと言う品番の機種がホビー用としてマーケティングされていた)、その為、だとしては破格の画像出力性能を持ってたんだ。
なお、実は内蔵ROM BASICだと、使える色数や解像度は制限されていて、ピクセル数はPC-8801の640x200に合わされている。だからここの実験だと、実際は128,000ピクセル、と言うのが操作対象で、カラー数も本来PC-9801が使えるカラー数より相当ショボいんだ(笑)。
何故?もっと使いこなしたい人は別売りの通称「DISK BASIC」をお買い上げください、と言う商売の為だな(笑)。
しかし、当時だと既に「PC-9801」の性能を使いこなしたい人はDISK BASICを買うよりC言語やPascalの言語処理系を買う事を選んでたと思う。
なお、アメリカでもPC-9801は発売されていて、結果マーケティング的には失敗したんだけど、Wizardryのプログラマ、ロバート・ウッドヘッドはPC-9801を入手していて、問題作「Wizardry IV」では開発用機材としては既にApple IIは使われてなく、北米版PC-9801を使用した、と言う話だ。
※8: それが故、一見、NECのマシンでも富士通のマシンでもはたまたIBMのマシンでも、同じ「MS-DOS」が走ってるように見えて、「✗✗用MS-DOS」と言った「専用OS」が作って売られていた遠因だ。もちろんマシンのシステム構成が違うから、コンパイルされた実行ファイルは違わなきゃならない、のは当然としても、この「各社入出力機構が全く違う」のを一つで吸収出来なかったのが遠因だ。
※9: なお、curseと言う単語は、英語では「呪い」と言う意味であり、「cursor optimization」の略称だ、と言ってもたちの悪いハッカー流の冗談、としか思えない名称だ。
※10: Steamなんかで売ってるMS-DOSのレトロゲームなんかは、基本的にDOSBOX同梱で売られている。
※11: なお、DOSBOXは極めて完成度が高く、往年のIBM-PCコンパチ機で動いていたMS-DOS用のゲームは「殆ど動く」と言って過言じゃない。また、これほど「プラットホームを選ばない」仮想マシンもなく、結果、Windows、iMac、Linuxで同じように動く・・・かつてのMacなんかは「喉から手が出る程」MS-DOSのソフトウェア資産に憧れたモノなんだけど、今になって往年のMS-DOSソフトを自在に動かせる、なんつーのは皮肉なモンだ。往年のMacintoshのソフトさえ動かないのに(笑)。
いや、笑い事じゃないんだ。Windowsでさえ、ヴァージョン違いになると途端に動かないソフトが多いのに、かつてのMS-DOSのソフトはDOSBOXならほぼ完璧に動かせるんだ。
結果DOSBOXはEternity、つまり永遠のソフトウェア資産を形成した。なおかつプラットホームを選ばないポータビリティがある。
ぶっちゃけ、「いつまでも使えるソフトウェア」を志向して、「プラットホームを選ばない」ソフトを書くなら敢えてDOSBOX向けにソフトを書くのが完璧な戦略なんじゃ?とかちと思うんだ。
DOSBOXは永遠に残る。と言う事は今「最新の」DOSBOX向けソフトを書いてもそれは「永遠に動くし残る」って事を意味するんじゃないか。
大体、実写クオリティのアニメーションとか、マジでゲームに必要か?256色同時出力程度でゲームには充分間に合うんじゃないだろうか。色数が増えて動画性能が上がると開発期間だけ増えて、しかもゲームの本質と関係ない部分ばっか金がかかる。そんなんだったらDOSBOX向けに面白いゲームを書いてた方が開発費も抑えられてエエんちゃうんか。
しかもマシンやOSのアップグレードに伴って「アップデート」する必要もない(笑)。そのうち、それに目を付ける企業が出てくるんじゃねぇの、とか予想してる。
既に往年のIBM-PCコンパチ機(486でSVGA)はレジェンダリなスタンダードの域になってるんだ。
※12: いや、実際、80年代のパソコンは出力用ハードウェア的に、「テキスト表示領域」と「グラフィック表示領域」が分かれてたりしていた。それは上下2分割のように設計されていたマシンもあったし、あるいはグラフィック領域にテキスト領域をインポーズ(重ね合わせ)して表示したりしたわけだけれども。
いずれにせよ、往年のホビーパソコンのような「端末エミュレータ」をデザインする事自体に技術的難しさはそこまで無いだろう。ホント、あとは「誰がそれを思いついて」「それを実装するのか」だけ、の話なんじゃないか。
※13: ちなみに、ある意味第三勢力があって、それがGNU EmacsでEmacs Lispを使う皆さんだ(笑)。彼らはまた、CLerともSchemerともポジションが違う。
Emacsはテキストエディタなんで、当然行指向なんだけど、端末に比べると画像を扱うのがラクだ。また、curses云々カンケーなく、キーボードの特定のキーとアクション(つまり関数だな)を結びつけるのも難しくない。
結果、GNU Emacsと言う「仮想マシン」相手にかつてのホビーパソコン相手にプログラミングを楽しんでいた、みたいな層が結構存在する(笑)。ハッキリ言っちゃえば、この20数年間のEmacsの発展に寄与してきたのは、彼らだ。彼らの「Emacs = ホビーパソコン」的な扱いがEmacsを「どんどん良くしてきた」んだ。
意外と、「ポータビリティ」を考えたゲームを書く、って前提だとEmacsも悪いプラットフォームじゃないんじゃないか、って気がしてる。テトリスだって動いてるし(笑)。
当然、エロゲみたいなアドベンチャーゲームも、実はEmacsなら簡単に実装出来るんじゃ?とか思ってる。RPGも。
誰もやってないだけ、で(笑)。
