第一回　ＤｉｒｅｃｔＸは一夜にしてならず（開発言語探求篇）

Ｗｉｎｄｏｗｓでまともなリアルタイムゲームを作ろうと思えば、まずＤｉｒｅｃｔＸを使うことである。ＤｉｒｅｃｔＸってなんじゃろかーってゆー人には、最終回までく冬眠していただくとして（眠りすぎや）、そうすると言語は何がいいんですかー？とか聞く奴がいる。いや、いるんだって！ほんと！

何がいいかって、そりゃ自作のコンパイラが一番いいに決まってっだろ！何せ自由度は∞だぜ〜。洗練度に欠けるＣ＋＋や、エミュレータにも劣るＪａｖａなんか目障りだからすべて無視せよ！そうだな。まずは、手始めにＡ．Ｖ．Ａｈｏの（誰がアダルトビデオ阿呆やねん！？）著書「Ｃｏｍｐｉｌｅｒｓ」をＩ・IIを買って来て読破したのちに、x86系アセンブラを覚えて、オール機械語（アセンブラでなくバイトコードね！）で自分だけのコンパイラ、つまり、最高の知的推論型論理エンジンを搭載し、「もうこのへんでいいっちゅーの！！」とか書くだけで、文脈からその意味を判断し的確なマシンコードに変換してくれる、きわめて生産性の高いコンパイラを制作することを第一目標とせよ！

．．．って、第一目標が高すぎるじゃん〜。まるで、万里の長城やね。いまので１０万人に一人も、残らんようなってしもた気がする。しょぼん。

そんなわけで、Ｍｉｃｒｏｓｏｆｔ系とＢｏｒｌａｎｄ系（知らない人は、ＹＡＭＡＨＡに並ぶ音楽メーカーだと思ってくれ！←なーんも知らん人間を地獄の底まで叩き落とす気か！）とどっちにしようかなというところにまで話を戻そう。いや、そんな話、一回も出てきとらんがな！！

ともかく、どちらがまともかと言えば、Ｂｏｒｌａｎｄ系だ。洗練度において、ＢｏｒｌａｎｄとＭｉｃｒｏｓｏｆｔとでは松坂牛と千年灸とぐらいの差はある。（ちっともわからん説明やな）　ＭｉｃｒｏｓｏｆｔのＭＦＣとかゆー奴は、実に汚く洗練されてないソースである。

自慢するわけではないが、３，４年ほど前、ＯｐｅｎＧＬがＷｉｎ９５で動き出したころ（そのころ、Ｗｉｎ９５でＯｐｅｎＧＬのプログラムを実行するにはＳoftＩmageの体験版とかからＯｐｅｎＧＬのｄｌｌをパクってこなければならなかった）、つまり、日本語のＯｐｅｎＧＬに関するまともな書物もなーんも出てないころに、突然、馬鹿遅のＷｉｎｄｏｗｓマシンとＶｉｓｕａｌ　Ｃ++とOpenGL ARB（OpenGL標準化団体）の書物（洋書だぜ）だけを手渡され、「ほな、来週までにこんなかのＭＦＣゆうの使って、ＯｐｅｎＧＬでグリグリ動く３Ｄビュアーを作ってきなちゃい！」と園長先生（誰やねん！）から指令が下ったときには、マジで死ぬかと思ったよ。Ｗｉｎｄｏｗｓマシンなんか遅いから、ＤＯＳしかイヤ！って思ってた我輩、初めてＷｉｎｄｏｗｓ触って、わけもわからんままプログラミングしたとき思ったねー。

なんでウィンドウにクラス一個が対応するの？そしたら、ウィンドウを拡張しようと思ったら、クラスの継承使うしかねーじゃん？最後に継承したクラスから派生させるとかそうゆーフレキシビリティのないＣ＋＋で、ウィンドウにクラス割り付けるなんて頭おかしいんでないの？と。あのときの衝撃はいまでも忘れてはいないし、二度とＭＦＣなんか触るまいと思ったねー。

なんか、ライブ感覚で書いてるんで、話が支離滅裂で申し訳ない。ともかく、Ｍｉｃｒｏｓｏｆｔのプログラムってーのは、どうも腐っているのである。開発ツール系が腐ってるから、自分ところでもバグだらけの腐ったプログラムしか作れないのではないかとか勘ぐっているのは私だけではないはずだ。そもそも、ＩＥ４．０を入れて、頻繁にメモリエラーとかで落ちるんで、友達に原因を聞いたら、Ｆｉｎｄｆａｓｔを常駐させてないかって言われて、そりゃＯｆｆｉｃｅ入れてるからスタートアップで読みに行ってるよって言ったら、あれは裏でファイル操作するからいますぐ消せと言われて、消したらそれ以来落ちなくなっただとか、Ｏｕｔｌｏｏｋ９８とＩＭＥ９８をセットで使っていると、特定の語を特定の順番で変換すると必ず落ちるから友達にその理由を聞いたら、ＩＭＥ９８の学習をオンにしてないかと。学習をオンにしていると、その学習結果をライトバックするときに、負荷がかかるからいますぐ学習をオフにせよだとか言われたとか（おかげでうちの環境では、いつまでたっても賢くならんがな！！）、自社製品との相性ぐらい見とけよ〜と言わずにはいられないとんでもない会社なのであるからして、ＤｉｒｅｃｔＸも、一応、ＶＣ＋＋から使うほうが他社製のコンパイラから使うよりは相性がいいんでないのとか何とか思う次第である。

（わけわからん文章でごめんね）

第ニ回　ＤｉｒｅｃｔＸは不毛なのねん（書籍探求篇）

そんなわけで、ハードウェア間のギャップを吸収し、ゲーム用の標準ＡＰＩをでべろっぱに提供するという目的から生まれたはずのＤｉｒｅｃｔＸが、非常に腐っていることに気づくのに、それほど時間はかからんかったわけよ。

ビデオメモリ間転送のやったら遅いMil系のビデオカードは言うに及ばず、巨大な画像転送するとメモリをロックするためか、音の歪むビデオカードやら、プライマリバッファをメインメモリに置いておかないと音量調整に失敗するＳｏｕｎｄＢｌａｓｔｅｒ系（これが仕様なんか？？）とか、いろいろあってやね、正しく使おうと思ったら、使用する前にさまざまなパフォーマンステストを行なって、最適なものを選択するような処理が必要なわけよ。おいおい．．．それは、DirectX側で受け持ってくれるべきものなんじゃないのー？

実際のところ、ｗａｖファイルを２つ読みこみ、それをDirectSoundを使用して同時に再生するというだけのプログラムであったとしても、それをＷｉｎｄｏｗｓのあらゆる機種で、あらゆる環境で、動作させようと思えば、相当高度な知識を要求される。そもそも、普通のプログラマにとって、そんなさまざまなマシンでチェックするようなことは出来ないから、自分のマシンで動くこと以外は保証できず、まともなプログラムを書くことなんて、不可能に近いなのだ。（ちょっと大袈裟かな？）

さらに言えば、ｗａｖデータをメモリに読みこむことすら、面倒なのである。ｗａｖデータをメモリに読みこむためには、ｗａｖデータがどんなフォーマットになっているかを知っていなければならない。それくらいＷｉｎｄｏｗｓプログラマの常識なのかも知れないが、やねうらおは知らないし、そういうのは知りたくもない。もちろん、そういうのを知りたければ、マルチメディアＡＰＩの本を買えばいいのだが、ｗａｖデータをメモリに読み込むためだけに１万円近い本を買おうだなんて、どうかしているとしか思えない。まっぴら御免である。

実践的には、DirectX SDKに、そういうサンプルがあって、それをコピー＆ペーストしてくるべきなのだが、コピー＆ペーストというのがどうも、好きになれない。美しくないし、不便である。すなわち、再利用するには、またもやコピー＆ペーストしてどこかに持って行く必要がある。そういうことは、旧石器時代の人間のすることであって、文明人のやるべき行為ではない。余談ではあるが、Ｗｉｎｄｏｗｓプログラミングになってから、コピー＆ペーストのお世話になることが多い。これは、ＤＯＳ時代よりさらに再生産性が低下していることを意味する。そのもっぱらの原因は、Ｖｉｓｕａｌ　Ｃ＋＋にあるのだが、これについては別の機会に譲る。

ともかく、そんなわけで非常に金のかかるプログラミング環境がＷｉｎｄｏｗｓであって、そんなところでＤｉｒｅｃｔＸまわりの処理を自分で一から勉強しようだなんて、気が狂っていると言われてもおかしくはない。そういう事情を何も知らなかった無知なやねうらおは、１からＤｉｒｅｃｔＸのライブラリを構築しようとして、まんまと地獄に堕ちた人間の一人であるからして、この発言の信憑性は高いはずだ。そもそも、まともにＤｉｒｅｃｔＸのライブラリを構築しようと思ったら、ＤｉｒｅｃｔＸの本が５冊は必要だ（著者自身が初期化まわりのことを正しく理解していないため、きちんとしたコードが書かれていないことがあるから比較検討する必要がある）。ＷｉｎｄｏｗｓのＡＰＩの本も５冊ほど必要だろう。まして、ＭＦＣも絡んでくるとなると、ｉｎｓｉｄｅ　ＭＦＣ等の本も必須となってくる。たぶん、それだけで１０万超えるんでないかなー。おまけに、そんだけ理解するのに、相当勉強せにゃならん。こんだけ受験時代に勉強してたら、東大受かってるぜ〜、ちゅーほど勉強しないといけない。それだけ投資して、フリーウェアで出そうだなんて、偽善者めいているというか、どこかウソっぽい。やねうらおが、フリーでソフトを提供する行為が、どことなく偽善者めいて見られたとしても、それはそれで正しい気がする。これについては、別の機会で話すとしよう。

そんな事情だからして、いまからゲームを作ろうという人が、一からライブラリを構築しようだなんてゆめゆめ思わないほうが良い。ではどうするのか？それは．．．

つづく（つづくんかい！！）

第三回　ＤｉｒｅｃｔＸはやめとけって（ライブラリ探求篇）

そんなわけで、やねうらおは、いまからＤｉｒｅｃｔＸの勉強をしようとかゆー奴を、「すげー気合入ってんなー」とか思う反面、「やめといたほーがいいんでないの？」とか思いながら羨望と侮蔑の眼差しで眺めている。（ごめん）

しかし余談だけど、Ｗｉｎｄｏｗｓでプロラミングしようと思ったら、日本語の書籍を買う金が無い輩は、ＭＳＤＮとかのオンラインマニュアルに頼るしかなく、英語が読めないと終わっているような気がする。ちゅーか、「英語も読めない愚民どもは、もう死になちゃい」とか、３歳ぐらいの国王に言われている気分がしてとっても腹が立つ。かくいうやねうらおも、あまり英語は、得意ではない。毎日、英文でやって来るe-mailに四苦八苦しながらも、なんとか仲良くなったところ、「今度、チャットしようぜ」とか言われて、「リアルタイムで英語話せまへんねん」といまさら断れなくて、チャットに出向いたら「wow!」とか「Yeah!」とか「really?」とか、感嘆詞ばっかりやんけ！みたいなチャットをして言語障害児とでも思われながら帰ってくるのがオチだからして、すらすら読むにはほど遠かったりする。（読むぐらい読めるんだけどね）

幸いにも、DirectXに関しては、DirectX5がリリースされた時点で、オンラインマニュアルの日本語化が行なわれたので、これで高い書籍を買わなくて済むのだが、このオンラインマニュアルとＳＤＫのサンプルだけでDirectXのプログラミングを行なおうというのは、相当に無謀である。レミングスのごとく、死に向かって爆進している姿にも思える。せめて、一冊は参考書を買うなりよ。

さて、DirectXには直接触りたくなければ（その方が懸命だ。人生は短いのに、そんなことに時間を費やすな！）、フリーで使用の出来るライブラリを探さなければならない。gooなどの検索サーバーでDirectXと入力。日本のサイトのみを対象として、検索すれば700件ほどしか出てこないからして、全部くまなく調べることぐらい容易なはずだ。えっ？とか思う人もいるだろうが、やねうらおは、全部くまなく見て回った。突きとめていけば同じところだったりするんで、７００ぐらい何でもない。これが出来ないような人は、たぶん、オンラインマニュアルから必要なところを検索するのも不可能っぽいから、いまのうちにプログラミングはやめた方がよいかも知れない。（などと言う奴．．）

ともかく、インターネットで配布されている日本語マニュアル付きのDirectXライブラリで使用に耐えるものは、以下の３つだけだと思う。（Direct3D専用のものなどは除く）

・ＷｉｎＧＬ（Ｂｉｏ100%作）
・ＤＸＭ（ぷよーん作）
・Ｅａｓｙ Ｌｉｎｋ Ｌｉｂｒａｒｙ（Botchy作）

順番に解説して行こう。ＷｉｎＧＬは、あのＢｉｏ100%が作っているだけあって、どんな環境でも最高のパフォーマンスを引き出すことが出来るように設計してある。（本当は、DirectX側がそういう処理をしてくれなければならないのだが．．．）不幸にも、使用はフリーだが、ソースを見るには5000円以上のレジストが必要で、こういうところで、金がかかるからDirectXプログラマーは、シェアウェアで公開せざるを得ないのであるなどと愚痴を言っても仕方がないのだが、まあ、DirectXの書籍を何冊も買うぐらいなら、素直にレジストしたほうが賢明かも知れない。やねうらおは、シェアウェアにレジストしないことを信念としているため、レジストしていない。よって、ソースの内容について深くは語れない。ただ、最近は開発が停滞しているようで、バージョンアップは望めないかも知れない。

次なるものは、ＤＸＭである。これは、ぷよーんさんの作品である。ぷよーんさんは、現在、コンピュータ系の学校の先生をされている。このライブラリは、ＭＦＣとＤｉｒｅｃｔＸを併用することを前提として書かれており、ゲームを作るための関数は、ひと通り用意されている。ソースもフリーなので、勉強のためにも入手したい一品である。

最後に、Ｅａｓｙ Ｌｉｎｋ　Ｌｉｂｒａｒｙである。こいつは、ソースフリーで、営利目的での使用も可という何とも男前なライブラリである。今月号のＣ MAGAZINE（９月号）にでかでかと記事が掲載されているので、ご存知の方も多いかも知れない。この作者の、Botchyさんは、本職のゲームプログラマで、このライブラリを使用して実際にゲームを作っておられるのだから、実用性については言うまでもない。DirectX6からサポートされるDirectMusic等に対応しているあたりも、好感が持てる。フルカラーモードでしか動作しないのが残念で仕方ないが、勉強用にソースを眺めてみるだけの価値はある。ソースを一部流用するのもＯＫとのこと。うーん！なんとゆー太っ腹！

以上、３つ。仮にＤｉｒｅｃｔＸのライブラリを一から構築するとしても、これらのソースは、手元に置いておくだけの価値がある。

第四回　コモンプラットホーム構想（たんなる夢）

今回は、DirectXの関連書籍の紹介でもしようと思ってたんだけど、DirectXは不毛なのでこんな鼻糞のようなテクノロジーに関与するのはあまりお勧めできない。そもそも、この連載、読んで為になることは書かないと誓っていることをすっかり忘れていた。

そこで、今回は、MAMEの話をする。MAMEというのは、汎用的なアーケイドゲームのエミュレータである。アーケイドのROMの入手して遊ぶのはillegalであるが、本体自体は別にillegalではない。たいてい、こういうことを書くと、どこで入手するんですか〜とか聞いてくる奴がいるが、んなもんぐらい検索サーバで自分で探せ！である。

このMAMEなのだが、基本的にＣで記述してあって、68KやZ80などをエミュレートするカーネルがある。そのため、移植が容易で、MACでも98(MS-DOS)でもDOSV(MS-DOS)でもWin95/98/NTでもX Winでも動くのである！JAVAでさえ、動くプラットフォームが限られていて、実用になる速度が出ていないのに対して、これだけのプラットフォームで音源やキーボードの同時押しまでサポートされていて、ゲームが快適に動作するとは驚きである。しかも、それがフリーで配布されているという事実！

Ｗｉｎｄｏｗｓソフトの大半がシェアウェア化する現在、これだけのテクノロジーが本体のみならず、ソースまでフリーで公開されているとはどういうことなんやねん？？

ずいぶんと理解に苦しんだが、たぶん、それは文化圏の違いだということだ。OSがWindowsで２万近くして、Visual Studio等開発ツールが10数万もかかる世界の住人には、自分の開発したもので金を取らざるを得ないし、何もかもがシェア化しているのだから、それはそれで当然なのである。逆に、Linuxなどで、OSや開発ツールをタダでソースまで入手できる文化圏に住んでいる住人にとっては、フリーでソースまで公開するのが常識なのである。すなわち、Windowsプログラムのシェア化は、バカ高い開発ツールと、書籍や関連資料で金のかかる開発環境などに起因しているのではないかと思う。（ＯＳが、安定しないとか腐っているとかゆーのも、その一端かも知れない）

そのへん愚痴り出すとキリがないので、もう少し建設的な方向で話を進めよう。まずは、JAVAのHOT SPOT技術についてである。こいつは、実行時に動的な解析をして、負荷の高い部分を最適化するというものである。ずいぶん前からアナウンスされているが、結局、それが実装できたのかどうかはいまだ知らない。

内容は、おそらく、関数の呼び出しカウントを調べておいて、ある時間内に、一定回数以上呼び出された関数を、コンパイルして、そのマシン固有のコードに置き換えてしまうというものでないかと思う。しかし、そもそも、あのJAVAの中間コードってのはなんか失敗しているような気がするのは、私だけではないはずだ。あんなダサダサなバイトコードを採用したのは、もちろんバイナリ互換をとるためなのだが、そもそもバイナリ互換なんか取る必要があるのか？まあ、仮に、あるとして、それを読みこみ時にマシン固有のコードに置き換えるぐらいたやすいはずなのに、どうしてそういうことをしないのか？あのＣにも似た言語セットで実用的な速度にならないのは、どうかしてるとしか思えない。ただし、Visual J++とか何を勘違いしたかWindows固有のコードを吐くが、んなもんはJAVAの設計理念を理解すらしていないからして論外である。

いま僕が作っているＢＭ　Ｒｅｖｏｌｕｔｉｏｎのほうは、そういう実験を兼ねている。
それが成功したら、コモンプラットホーム構想に乗りだそうかと思っている。内容は、

１．ゲーム開発専用の言語を提供

もち、コンパイラもフリーで付属してるから、Visual Studioとか馬鹿高い開発ソフトを購入する必要がないし、ゲームのためのスプライト表示やサウンドがらみの関数を内包してるんで、DirectXとか不毛な勉強をする必要がない。

２．コモンプラットホーム

その言語で書けば、あらゆるプラットホーム（少なくともMAMEの動くプラットホーム）で動作が保証される！

そもそも、MAMEでもそうだが、ゲーム系というのはメインの処理はわずかで、描画まわりと音源がらみがほとんどなのであるからして、メインのコードの最適化なされていなくとも、実用的な速度になるのである。

うーん。夢のような構想。誰か手伝って！　←　手伝ってもらわんと出来んのかい！！

第五回　DirectX5は腐ってるんか？（不満ぶちまけ篇）

DirectX5（以下DX5）ってーのは、ご存知の通り、ＷｉｎｄｏｗｓＮＴでは動かない。現在のＮＴ４．０ではDirectX3（以下DX3）までしか対応していないからである。どうして対応しないのか、やねうらおには、その真意を計かり兼ねるが、一言で言うと、悪質な嫌がらせとしか思えない。まあ、そのへんは次期ＮＴで対応されるとしても、どうしてWin95/98で動作するものが、その親分格であり豪華版でもあるＮＴで”そのまま”動作しないのか、一体どれだけ腐った設計をすれば気が済むのか、凶悪魔人Windowsは、しおしおプログラマなやねうらおの想像を遥かに超越している。（ごめん。単なる嫌味）

まず、DX3とDX5の違いは、主に3D回りの新機能を除けば、DirectInputだけである。ちゅーことは、二次元のゲームでなら、そのへんさえ自前で書いてやれば別にDX3で十分なわけであって、NTで動作するわけだ。しかしやね、しかし。いまDX5で満足に動いてるものを誰が好き好んでNTに対応させるためだけに大幅変更／修正せにゃならんのよ？んなもん、ＮＴ側が対応してくれるべき問題でしょ？

そういやDirectDrawのドライバが腐っていて、Vram（ビデオメモリ）にサーフェイスを作るとやたら遅いなんてバグも存在した。優秀なDirectXのアプリなら、そのへんパフォーマンスチェックなりを事前に行なうわけだが、やねうらおに言わせれば、「なんでそんなんせんとあかんかな〜」である。腐っているのはドライバ側なんだから、ドライバ側が修正すべきである。でも、そういう事情をてんで知らないユーザー様は、「ほにゃららのソフトでは問題なく動いているんだから、やっぱしお宅のソフトが腐ってるんでないの」みたいな言い掛かりをつけてくる。待ってくれ。ほにゃららのソフトが機嫌よー動いてはるんは涙ぐましい努力があるんや。それは商売やから、仕方なくバグと欠陥だらけのWindowsの尻拭いを、汗と涙を流し、ときに徹夜しながら眠い目をこすりこすりやってることなんや。わしにそんなこと要求すなや！と言いたくなる。

DirectXの話がだんだん暗礁に乗り上げてきたところで、こいつが利用しているActiveXとゆーテクノロジについても書く。ActiveXは、狭義には、OLE2の拡張であって、基本的に、COM(コンポーネントオブジェクトモデル)なわけだ。どんなことが出来るかというと、あるプログラムから別のプログラムの関数が呼び出せる。主なメリットは、それだけである。そのインターフェースの規約みたいなものだと考えれば良い。つまり、インターフェースの規約なのだから、そこで使用されている開発言語は何でも良いはずだ。どんな言語からでも、任意の言語で開発されたプログラムを呼び出すことが出来る・・・はずだ。しかし、実際、そうではない。簡単にその理由を述べれば、インターフェースを定義するのにＣ＋＋風の表記が必要だからである。結局のところ、ＶＢで作ったプログラムをＶＣからＣＯＭを利用して呼び出すためには相当やっかいなことが待ちうけているのだ。そのへんのコンバータぐらい用意しとけよと言いたくなる。言うまでもなくDirectXにしても、ＶＢからは直接利用できない。自社の開発言語でさえ利用できないCOMテクノロジーというのがどこまで腐ったテクノロジーであるかは言わずもがなである。

第六回　実はＣ言語ってよー知らんねん（ごめん俺が悪かったの巻）

実は、やねうらおはＣ言語（Ｃ＋＋を含む）はあまり好きでない。そもそも、よく知らない。これは冗談でも何でもない。ただ、よく知らないと言っても、ビートマニアやDance Dance Revolutionのようなゲームを作るぐらいは出来るし、Ｃ＋＋で他言語のコンパイラを実装するぐらいのことも出来る。さすがに、そこまで落ちぶれてはいないからして．．．。

知らないというのは、「そんなん知ってて何の役に立つかな〜」的なＣ言語固有の問題をてんで知らないということである。Ｃ言語固有の問題でなければ、勉強になるような気もするが、なんとか固有の問題というのは実にヤらしい。ヤらしいついでに、その筋のマニア（プロと呼ぶにはあまりにも言うことがプラグマティックではない僕の知人！）は、ことあるごとに「えっ？そんなことも知らないんですか？ANSI Cのドラフトx.xxでは、以下のように定義されてます」みたいに書いては英文を引用してきやがる。「一度、ANSI Cのドラフトすべてに目を通されてみては？」んなこと出来っかい！だいたいなー、そんなことも知らないんですかやあらへんがな！せめて「それについては、Ｃ言語が発展してくる過程であまりにも広いプラットホームを対象としたがために起こった機種依存性の問題でして、残念ながらＣ言語では、以下のような仕様になっているのです」となんで言われへんかな？いや、そこまで丁寧に言われても困るけど、もうちっと言い方考えろよー、みたいな。

話がそれた。Ｃ言語固有の問題にあまりかかわりたくないし、出来ることなら、機種依存な問題にもかかわりたくない。だからして、ひとたび書けば、それがどこでも動くJavaの理念には強く心惹かれるものがあった。一応、過去形だ。何を隠そう、僕はJDK1.02αのころ、英文のオンラインマニュアルだけを頼りに33MHzの486DXでプログラムを開発して遊んでいた。たぶん、日本でもかなり先駆的にJavaと関わっていたはずだ。ついでに言えば、見捨てる早さも先駆的だった。下手すると日本で１，２を争う早さ。まったく誉められたことではないのだが。

この連載の第一回でも言った通り、ゲームを作るのに使用する言語なんてＣしかないわけじゃないんだから、嫌ならさっさと見きりをつけて自分でオリジナルのコンパイラでも作ってしまったほうがよっぽど健全だ。僕はFortranでプログラムを組めと言われたら、気が狂うと嫌だから、ＣからFortranにコンバートするプログラムを書く。いや、実際に、そうした。僕が大学に入りたてのころの話だ。（それは自慢ではない。yaccを使うほどでもない、ある程度の規則に従って単純に文字置換するだけのプログラムである）　余談だが、このときFortranを教えていた教授とはえらく仲が悪かった。「汎用機の世界ではいまだにFortranが強く根ざしており君たちはFortranを使えなければならない」なんて馬鹿な講義されると、んなもん使うぐらいなら、世界中の汎用機のクロスコンパイラかたっぱしから作ったるわーと叫びたくなるやねうらおだからして、はなっから仲良くなれるはずがない。おまけにＣからFortranにコンバートするプログラムを作ったというのに、評定は優・良・可・不可の可。ナンタルチア！なめとんのかお前！と言いたくなる。そりゃ、２回目の講義から最終回までほとんど出席は代筆だったかも知れないけどよー、２回ともレポート出したのに、そりゃあんまりでないのー？そういや、あんときのレポートのうち一回は、時間がなかったから、友達のやつコピーして変数名変えただけだったことをいまのいまになって思い出した。人間、誰しも自分にとって都合の悪いことは綺麗さっぱり忘れるように出来ているのであった．．．。

第七回　バイナリ互換性は必要なのよね〜ん（8x86はJavaをも超えるんか？）

Javaのバイナリ互換性（意味のわからん人は、このキーワードが出てくるごとに、キテレツ大百科に出てきた黄色のチョンマゲをしたコロ助とか言う人形を頭に浮かべ、倍ナリ！倍ナリよ！と力んでみること。←よけー混乱するっちゅーの！）は必要かということを第四回で話題に出したが、これは、突き詰めて行くと難しい。

BSDとLinuxのソフトはソースレベルでの互換性があるにも拘らず、バイナリ互換性がない。つまりは、ソースがない限りは、Linuxで動作しているものをBSDに持っていくことは出来ないのだ。（幸いにも、BSD上でLinuxのバイナリを動かすためのパッチがあるので、そのへんはなんとかなるのだが）

そもそもソースっちゅーのは一般に企業機密だからして、ソースコンパチであっても、ユーザーにとってたいしたメリットはない。バイナリ互換性は、今後、ＯＳをまたぐソフトを開発／使用していかなければならない者にとって必須事項なのである。

理想的には、バイナリ互換性のある汎用言語（Javaのような仮想マシン用のバイトコード＝中間言語）にしておいて、それを各機種でjust in timeなコンパイラ（必要になったときにのみ必要なだけコンパイルする／量が少なければ読みこみ時に一括してやってしまっても良い）によってネイティブコードに変換するものが良い。そうすれば、バイナリ互換性があり、かつ、それなりの速度が維持出来るからである。

単純には、Javaが実用になる速度になれば良い。あと、JavaがグラフィックやマルチメディアまわりをDirectXかOpenGL並に標準でサポートしてくれれば良い。その二点の条件が揃って初めて、汎用的なプラットホームで実用的なゲームの開発が行なえる。

しかし、それをJavaに望むのはちょっと不可能っぽい。だからこそ、第四回のコモンプラットホーム構想が意味を持ち得たわけだ。

それでもやね、CPU間のコード変換、たとえば8x86のコードを68Kのコードに変換するのは、下手なコンパイラを作るぐらいに簡単だからして、機種依存部分に対する呼び出し規約だけ決めてしまって、ロジック部分は、仮想マシンだなんてケチなこと言わずに、8x86用（すなわちWindows用）にガシガシと書けば、簡単にバイナリ互換なプログラミングの開発が出来るのではないかというのが、やねうらお式のコモンプラットホーム構想である。エミュレーションを行なうだなんて、ダサイことをしないところがこの技術の重要なところである。

第八回　だからＣ言語オタクって嫌いなのねん（Ｃマガの記事に横槍を入れるの巻）

どうでも良い話だが、今月号のＣマガ（９８年１０月号）での真紀俊男という奴の記事がちょっと気になるので、まずは、それを紹介する。やねうらおと名前がなんとなく似てるので、あれってやねさんですか？と何度かたずねられたことがあるが、同じような分野を歩いてきた匂いはするが、まったくもって別人だからしてそこんとこ誤解しないように。ただ、やねうらおは何故か、Ｃマガは毎月タダで頂戴していたりするが．．．

さて、今回の真紀俊男の記事は、インターネットにはびこる初心者向けＣ言語講座にありがちなミスについて特定一個人のＨＰの内容を事細かに取り上げて突っ込みを入れるというものである。どうも、そのこと自体、大人げない気もするのだが、まあ、一般的にありがちなミスを取り上げているということなら、まあ良しとしよう。その特定一個人ってーのが、アセンブラあがりで、まー、Ｃ言語の仕様と実装の区別もついてない鼻垂れオタクっぽいのだが、そんな奴は、山のようにいるわけで、そいつが自分のＨＰでサンプルとして書いていたプログラム：

void main(void)
{
　　　　　printf("hello");
}

のvoid mainがANSI Cに準拠していないことと、改行コードが入っていないから、ストリームのフラッシュが行なわれず、これだけでは表示されない可能性があるとか、まー、そーゆー指摘を真紀俊男がしているのである。

第六回でも書いたけど、なんでそんな指摘の仕方しかできひんかなー？このvoid main(void)ってーのは、K&R第1版でサンプルにmain() { ... と書いてあったから、省略時はvoid main()の意味と勘違いしたところに端を発するようなのだが、真紀俊男が「傑作だったのは」と書いて馬鹿にしているのは、どうもおかしいと思う。

確かにＣ言語で関数の返し値の型を省略した時はintってーのは常識かも知れないが、それにしてもそれを知らんからて、「傑作だったのは」はないんとちゃうかー？省略したときはあらへんねんから、当然voidやと思うんが、人間の心理とちゃうんかー？むしろＣ言語の仕様のほーが、不条理やとは思わんのかー？それを知らんことがそんなに”傑作”なんかー？そういうのを知らんと、初心者相手にＣ言語講座を善意で（だってインターネットでそんなんやっても誰も一円もくれまへんがな！）やるんが、そんなに罪深いことなんかー？どうして、省略時にintになってるか、それをちっとでも考えたことあるんか？不自然だと感じたことはあらへんのか？そういうところに不満を感じ、仕様だからとか規格だからとか言って無前提にそれを許容しない態度で臨んでいれば、そーゆーハナタレオタクの言うことに対しても、もっと寛容に接することも出来ると思うのだが？

どうも、いまのプログラマは、間違ったプログラミング教育を受けてきたせいか（あるいは、教育を受けずに独学でのみ学んできたせいか）、自分たち以下の技術者に対して、間違った指導しか出来ていない。それに、言語設計をやったことのないものは皆、言語仕様を絶対的なものとして受容し、それを知らぬ者を足蹴にしているような気がしてならない。

Ｃ言語の言語仕様は醜悪で、腐っているからＣ言語を使うのはやめなさいと何故誰も言わないんだろう？（C言語のNewsGroupでそんなことを言おうものなら袋叩きにされるという話もあるが...）　それを言っちゃおしまいだよ、と言われるかも知れないが、それを言わずして何が始まるというのか？

戻る