時、巻き戻った後11
とりあえず、輪太郎は開発環境を絞り込むことを始めます２。
そう、問題は、開発言語。
プログラムで金を稼ごうとするなら、重要になるのは開発言語だ。
この時代、無料で使える言語はほとんどがインタプリタである。
PC-9801系統の場合、標準搭載のBASICであるN88-BASIC(86)がもうインタプリタである。
パソコン内部のROMに書き込まれており、電源を入れるとすぐに読み込まれ、起動と同時に使う事が出来て、プログラムも簡単。
大変便利なN88-BASICであるが当然欠点もある。
実行速度も遅いし、人が読み込んで、人が実行しないと起動しない。
だから、ディスクを入れて電源入れるだけで自動起動、なんてのは夢また夢だ。
また、プログラムのソースファイルも生のテキストファイルで、ホビーとしてパソコンを扱えるレベルの人ならコピーし放題、改造し放題である。
デメリットが速度だけなら対策はある。
遅い部分だけマシン語にすればいい。
BASICからマシン語を呼び出しすれば速度面は解決できる。
しかし、ソースコードがテキストと言うのだけはどうにもならない。
すぐにコピーされてしまうし、変更されたらダメな部分も改変できてしまう。
プログラムの内容について、安全が保証出来ないものを売るのはダメでしょう。
まあ、作ったゲームを雑誌に掲載してもらうとか、そういう用途ならBASICでも問題ないし。
用途に応じて使い分けるべきなんだろうね。
ただ、今回の場合、まずソフトを売らなきゃいけない。
そういうわけで、インタプリタ系統の言語は選べない、と。
じゃあ、商品にできるプログラムってどういう物なのか。
端的に言うと実行ファイルが生成されるプログラムがそうだ。
実行ファイルが作れれば、ソースファイルを直接配布する必要がない。
つまり、プログラムに対する勝手な改変を避けることができる。
作成されたソフトについて、少なくとも作成者の意図通り動く保証は出来る形だ。
じゃ、どうすれば実行ファイルが生成できるのか？
コンパイラ系の言語を使えば良い。
コンパイラはソースファイルから実行ファイルを作る形の言語である。
ソースファイルの頭から順番にマシン語に置き換え、それを実行ファイルにする。
生成された実行ファイルはマシン語で記述されてているので、実行速度も速くなる。
一石二鳥である。
問題は、この時代のコンパイル系言語に無償のものはほとんどないということだ。
特に比較的新しい言語だったCは、この傾向が高くて値段も高い。
今年(1985年)の4月に販売されたMicrosoft C 3.0というCコンパイラがある。
国内最初のMicrosoft謹製のCであり、みんなが欲しがる開発環境なのであるが・・・。
この市販価格が1本40万円。当時の新卒大学生の初任給の3か月分である。
いくら業務用ソフトとはいえ手加減してほしいこのお値段。
ほかのCコンパイラで人気があったものだと、Lattice Cというのもある。
ファミコンの時に出たACT65マクロアセンブラの入手元である米Lifeboat社製のMS-DOS用コンパイラで、日本語版のJ3.10が9万8千円。
お値段的にはだいぶましだがそれでもほぼほぼ10万円コースだ。
ちなみにこれでも下がった方で、1982年にリリースされた当初のお値段は$500。
日本円に直すと12万4千5百円である。(当時の為替の1ドル249円で計算)
あー、ちなみに、Lattice Cはそこそこ信用があった。
マイクロソフトがライセンスを買って、一時はMS-Cの初期バージョンとして使われていたこともある。
MS-Cもバージョン3からは完全にマイクロソフトで内製されるようになったが。
ちなみに、Lattice Cには個人使用版と言うのもあって、これなら\19,800-で購入できる。
が、商用製品には使えないんだよな。これが。
もう気持ち安いコンパイラだと、Desmet-Cというのもある。
MS-DOS上で動作するCコンパイラで、これもアメリカ製。
最終的にはANSI C規格まで対応していた小規模コンパイラだ。
国内販売もされており、ソフトウエアインターナショナルという会社から販売されていた。
お値段9万2千円、やっぱり10万円コースである。
Lattice Cと比べて価格差6千円。
安いと言えば安い、位かなあ。
それ以外となると、かなり新しいコンパイラになる。
1988年くらいに登場する格安高速CコンパイラのTurbo Cあたりがそれに該当する。
残念ながらこれを利用するとなると、このあと3年も無為に待つことになるうえ、Turbo C側でもライセンスの縛りがある。
廉価な個人開発用のパッケージで業務開発を行おうとすると制約が多くて、やっぱり高価なパッケージを選ぶしかなくなるんだよな。
Cコンパイラでかつ、無料か格安の物・・・あるか？そんなもん・・・。
まあ、ないな。
多分ない。
フリーのCってだけだとgccとかもあるが、あれが公開されるのは1987年、しかも使える環境はUNIX用からのスタートだったよなあ・・・。
MS-DOSとかまだまだ全然先だろうし。
I/Oとかの雑誌掲載のコンテスト受賞作あたりで軽量版で機能が足りないCコンパイラの実装は何度か見かけた気はするが・・・。
さすがにそんなもので商用プログラム書くのは緩慢な自殺でしかないし・・・。
つなぎとして１～２万のコンパイラを買う手はあるかもしれないが、乗り換え後の互換性問題がなあ。
てことは、割れ物でも持ってこない限り、最初からCコンパイラで開発する線はないかー。
となると、この時代にある言語って・・・Fortran、COBOL、PL/I、Prolog、Pascal、Lisp、Smaltalk辺り・・・・ないわ。
ほとんどUNIXかそれ以前のメインフレーム由来の言語だよなあ。
唯一、SmalltalkだけがXerox Alto用というくらいか。
MS-DOS処理系で使える実績があるのはPascalくらいだけど、PascalってDelphi出るまでDOS系・・・特にPC-9801系 MS-DOS用の処理系あったっけ？
Delphiの前・・・Turbo Pascalだっけ？
あれはMS-DOSでも使えた気がするけど、Turbo Cと同時期の発売だった気がするから登場は87年か88年になる気がする。
そもそもPC-9801環境で使えたっけ？IBMコンパチ機だけだっけ？
どうだったかなあ・・・・。使ってなかったからなあ・・・。
あ、そういえばもう少し後ならN88-BASICコンパイラの線もあるな。
ああ、もしかしたらBASICなのにコンパイラ？と疑問に思うかもしれないな。
ここで言っているのは所謂MS-DOS版のN88-日本語BASIC(86)のことだ。
専用ディスクからBASICのみが起動する所謂DISK-BASICとはちょっと違う。
ROM版と違い、インタプリタとしてだけでなく、コンパイラとしても使えたのが特徴で、当然実行ファイルを作成することもできた。
つまり、BASICのソースファイルからバイナリが生成でき、実行速度も早くなるという代物だ。
とは言え、実行時ランタイムが必要なうえ、実行ファイルの中身は中間ファイル形式だったりとなんだかJAVAっぽい作りで、あれはあれでなかなか面白い仕組みだった。
ただ、残念ながらこれも、俺が使うには登場がやや遅い。
MS-DOS ver5位の登場だったからなあ。
うーん、思いつかない。
BASIC内のマシン語に限れば、ハンドアセンブルしてPC-9801内のモニタモードで書いてやる手もあるけど、あれは直接バイナリにならないし・・・。
やっぱり、プログラムを販売するなら何らかのコンパイル系言語は必要だよなあ。
けど、こう高額ではプログラムが売れないと有料のコンパイラは入手出来そうにないし・・・。
お年玉とかクリスマスプレゼントで買ってもらえそうな値段ならなんとかするんだが、それができるようになるの、Turbo Cからだよなあ。
金がないのは首が無いのと同じって言葉が身に染みるわ。
何か裏道ないかなあ・・・。
うーん、裏道・裏道・コンパイラ・ハンドアセンブル・機械語・自動化・・・
うん？そういえばアセンブラ言語は検討してなかったな。
マイクロソフト系のアセンブラ言語というとMASM(Microsoft Macro Assembler)だろう。
Visual Studioに含まれるMicrosoft Visual C++ とかの中にさらに同梱されてたやつ。
あれってたしか、最初はMS-DOSのバンドル品だった8086系アセンブラだったんじゃなかったっけ？
リンカごと入ってて、リンカだけずっとMS-DOSと同梱だったんだよね。
あれも、ちょうどMS-DOS 3.1あたりの時代の話だったような・・・。
あれならインラインアセンブラでコード書いた事あるし、アセンブラ処理部分の単体動作確認のためにMASM自体も使ったことあるから物になるんじゃないかな？
あのころ使ってたVisual C++ 付属のMASMに比べると機能は少なくなるだろうけど、そもそも時代的には8086時代に戻る訳だから、実装自体は容易になるんじゃ？
何しろ、8086に存在したインストラクションコードだけしか使えなくなるわけだから。
けど、8086時代はあっても、その後のx64時代には残っていないインストラクションコードって互換性を重視していたIntelの方針を考えると、考えにくいと思うんだよね。
しいて言えばNECのカスタムチップであるV30専用の命令についてはMASMで取り扱えないかもしれないけど、そもそも、互換性を考えると最初から使わない方がいい命令群なんだろうし。
もし必要になっても、アセンブラのマクロ機能で不足してるインストラクションだけ追加すればいいので問題は少ない。データシート見ながらしこしこ書き加えればいいだけだ。
アセンブラであれば、コンパイル系言語同様直接実行ファイル生成ができるので、ハンドアセンブルよりはずっと早く開発できるはず。
何より、他言語に比べると完成したバイナリの実行速度が圧倒的に早いのがいいやね。
MASMがMS-DOSにバンドルされているのが確実なら、言語仕様やリファレンス辺りもMS-DOSのマニュアルに同梱されている可能性が高いだろうし、8086についてなら十分知識がある。
つまり、MASMがついてるMS-DOSさえ購入出来れば、いきなり商用ソフトの開発に手をだして問題ないかも・・・。
うん、本体さえ調達できればなんとか行けるんじゃないか？
だんだんそんな気がしてきたぞ。
