このページは、プログラミングというものを１度は経験したことのある方を対象にしています。

目次
１．FORTRAN、COBOL の時代
２．C、Lisp の時代
３．Visual Basic の時代
４．C++ Builder の時代
５．Visual C++ の時代
６．おわりに

C でバックトラックのアルゴリズムを使ったプログラムを作らなければならなくなった。数学の時間に樹形図というのをかいたことがある人もあるかと思うが、バックトラックというのはそれをプログラミングすると思えばいい。樹形図をたどっていってうまくいかないときは元に戻って他の場合でやりなおすというアルゴリズムである。場合分けがきれいに行く場合を除いては、このプログラミングは FORTRAN では作れない。というのはリカーシブコールというサブルーチンから自分自身を呼ぶというプログラミングが必要である。
かなり熟知してもらわないと実際に理解してもらうことは難しいが、実はこのリカーシブコールができるとできないとではプログラミングに雲泥の差ができる。a! Reg Analyzerはリカーシブコールを多用しているし、またそうしないと作れない。このときリカーシブコール以外に C のポインタ（概念的には理解できるが慣れないとかなり難しい、ここでつまずく人が多い）と構造体について学ぶことができた。
私が C のポインタを使うときは ptr + n（ptr:ポインタ、n:整数）というコーディングは余りしない。大抵 &prt[n] という書き方をする。その方が理解しやすいからだ。皆さんにもお勧めする。
Lisp も学ぶ機会を得た。Lisp はリカーシブコールのかたまりのような言語だ。Lisp はリスト構造という構造のみを使い、それは非常に多くの括弧対によって表現される。もうひとつの Lisp の特徴としてプログラムもリスト構造、データもリスト構造ということがある。このため「プログラムを作るプログラムを簡単に作れる」。どういうことかというと Visual Basic の Print 文で Visual Basic のソースを作るようなものである。この場合出来上がったソースをもう一度コピー＆ペーストしてきて実行するとことになるが、Lisp はその必要は無い。データに対して Eval を行なうだけでそれがプログラムとして動く。これは他の言語に無い特徴である。
このときオブジェクト指向プログラミングの C++ も少し学んだが、実際にはテストプログラムを数行書いただけであった。オブジェクト指向の本も読んではみたが、眠くなるだけで全然わからなかった。本のタイトルは忘れたが、きっとこんな本を書くやつは実際はわかっていないのに知ったかぶりをして書いているだけなんだ。しかし C++ の仕様を勉強してなんとなくわかった。「要するにサブルーチンと変数を合体すればオブジェクトになるのだ。」

Excel で表の処理のプログラミングをする事になった。このマクロ言語を学んだときはプログラミングの革命かと思った。画面は対話的に作成できる。ビジュアルプログラミングという。またオブジェクト指向している。オブジェクトのサブルーチン（正式名称はメソッド）と変数（正式名称はプロパティ）には".(period)"でアクセスできる。もうひとつ新規の概念にイベントというのがあった。これは例えばボタンをクリックしたときとかチェックボックスをチェックしたときに発生するものらしい。そいつに対してどのような処理を行なうかを記述する。その結果以前のプログラミングでは考えられないプログラミングになった。通常のプログラミングはメインプログラムとサブルーチンがあり相互につながりツリー構造になるのだが Visual Basic の場合はメインプログラムがあったりなかったりする。更にサブルーチン（正確に言うとイベント処理ルーチン）がメインプログラムと全然つながっていない。つなげる何かがあると感じてはいたが、それを本当に理解するのは Visual C++ の時代まで待たなければならなかった。
Visual Basic に関してはある程度達人になった。C++ は知っていたので、この頃 Visual C++ を１週間ほどかけて勉強したことがあった。全くわからなかった。チュートリアルの Scribble の例題をその通りにやることはできるが中身を全然理解できない。暫く経ってもう一度１週間かけて挑戦してみた。ダメだった。よってあきらめることにした。「私の会社はソフトを専門につくる会社じゃない。こんな言語で開発しても、開発費を回収できる訳が無い。」
Visual Basic でどうしてもできないことがあったら Declare 文を使って Windows の API（Application Programming Interface）を呼ぶことを知った。API とはマイクロソフトが用意した Windows のサブルーチンライブラリのことである。自宅にパソコンを買い、最初はゲームでもやっていたのだがそれにも飽きてしまって、オンラインソフトを開発して公開することにした。初めて公開したのがScreen Saver Stopperである。当然 Visual Basic で作った。
この頃「Inside Windows」という雑誌が出ていた（今は廃刊になってしまった。残念！）。中身はほとんどわからなかったが見栄で１９９６年９月号を買ってみた。その中に Windows Programming Tips というコーナーがあり、ほんの４頁だけれどもタスクトレイにアイコンを出す Visual C++ のプログラムが出ていた。Shell_NotifyIcon という API を使えばアイコンが出るのだなと考え Visual Basic から呼んでみると、なんと出た。しかし当然のことながらアイコンをクリックしても何の反応も無い。
他方 Visual Basic のマニュアルの中に「ウィンドウズのサブクラス化」というのが出ていた。この例題も打ち込んでやってみていた。メッセージフックみたいなことをするらしい。メッセージフックというキーワードはあちこちで聞いていたのだが、全然わからなかった。例題はその通りに打ったのでもちろん動いた。
ここでピンときてしまった。「２つの例題をくっつけてみよう。そうすればタスクトレイのアイコンのクリックを感知できるのではないか！」いとも簡単に成功してしまった。Windows というはメッセージがウインドウ間をいろいろ飛び回っているものらしい。マウスクリックも１つのメッセージでそれを感知するようにすればいいのだ。ここでメッセージという言葉とイベントという言葉が結びついた。「そうか！イベントとはメッセージと考えればいいのか」。この技術を用いて第２段のオンラインソフトMulti Function Alarmと第３段Deeper Folder Opener（今の名前は a! Menu Filer）ができた。

Deeper Folder Opener はその名の通り深いフォルダを開けるソフトだったが、作成してみると API の呼び出しのお化けのようになっていて Declare 文がソースの３分の１をしめるという異常な状態であった。このままでもよかったのだが将来的にもっとお化けになるのもいやなので、次のプログラミング言語を考えることにした。条件としては２つあった。(1)API が呼べること（これは当然）(2)ランタイムがいらないこと（Visual Basic のランタイムはどこにありますかというメールばかり来ていた。）このときボーランド（今はインプライズ）社からダイレクトメールが届いた。そもそもダイレクトメールは嫌いなのだが、このときだけは運命的なものを感じた。上記条件に当てはまるものとして C++ Builder と Delphi ２つがあったのだが C++ を少しかじっていたのと Delphi が１万円高かったという理由で C++ Builder Standard Edition を買うことにした。
私のオンラインソフトの全て（まだ３つ）を Visual Basic から C++ Builder に移行した。特に違和感は無かった。VCL（Visual Component Library）という優秀なクラスライブラリがあり、完全な機能の移行はできなかったが大きな問題はなかった。Visual Basic のコントロールにあたるコンポーネントは種類も豊富でプロパティもたくさんあった。しかも憎らしいほどよくできている。こういうことしたいなと思うプロパティがあったり、これは開発経験から作ったなと思える便利なメソッドがあったりした。
ボーランド社から次のダイレクトメールが届いた。世の常バージョンアップのお知らせである。いろいろ迷ったが締め切り間際になって C++ Builder 3.0 Professional Edition へバージョンアップすることにした。この頃Before Power Offという新規ソフトも公開していた。Screen Saver Stopper Multi Function Alarm Before Power Off は問題無く移行できた。ところがである。Deeper Folder Opener を改名したDeeper File Opener のファイルをクリップボードへコピーする機能が働かない。いろいろ試してボーランドにサポートをお願いするＦＡＸを送った。返ってきた返事は「ボーランド社の範囲外の仕様変更があるようです。」との事。その中身までは教えてくれなかった。というよりはサポート側が知らないんだと感じた。「ボーランドの馬鹿やろう。お金返せ！」と思った。実はかなり後になってそれは正しいことがわかった。CoInitialize 関数ではなく OleInitialize 関数を呼ばなければならない。当時はそれがわからず２つのバージョンの違うコンパイラを１つのパソコンに入れたくなかったので泣く泣くScreen Saver Stopper Multi Function Alarm Before Power Off を前の C++ Builder Standard Edition へと戻した。

私はDeeper File Opener をファイラにまで高めたかった。フォルダの中のファイルの操作を直接メニューから行ないたいとずっと思っていたが、その方法がようやくわかった。コンテキストメニューハンドラという DLL を作ればできるらしい。その例題は Visual C++ 2.0 で書かれてあった。ところが C++ Builder にどうしても移行できなかった（当時のバージョンではできなかったかもしれないが今の最新バージョンならできそうである）。結局そのとき持っていた Visual C++ 5.0 で DLL を作ることにした。この頃は C++ Builder のおかげで色々な知識も増え Visual C++ がなんとなくわかるようになってきていたのだ。
この際 MFC（Microsoft Foundation Class）を使わないことにした。MFC というのはマイクロソフトが提供しているクラスライブラリである。かつて API はサブルーチンライブラリであると述べた。イメージ的には C で作られているライブラリが API で C++ で作られているライブラリが MFC と思えばいい。しかし MFC を使うとなんとランタイムの配布が必要になるのだ。更にこのランタイムが Visual C++ のバージョンによって異なるなんてとんでもない話だ。DLL Hell の状況を自ら作っているのだから。Windows 2000 では「DLL Hell の終焉」といって欠点を宣伝文句にしてしまうのだからマイクロソフトの商魂はたくましい。私は既にそれを回避するために、ずっとランタイムが不要なソフトを作っているのだから。じゃあ API もランタイムがいるのではないかと思われた人もいるかもしれない。実は API は Kernel32.dll, User32.dll, Gdi32.dll 等の Windows で最も基本的な DLL を直接呼び出している。従って MFC を使わず API だけでプログラムを作ったとしてもこれら DLL だけは必要である。但しこれらの DLL がひとつでも欠ければ Windows 自体が動かない。ランタイムとはこれら DLL との仲立ちをして使いやすくするものである。これを一般にラッパー（包むもの）という。
MFC を試験的に使ってみたのだが C++ Builder の VCL と違って API 他ウインドウズプログラミングをかなり熟知していないと作れない。つまり MFC プログラミングでは MFC に加えて API、ウインドウズプログラミングをも覚えなければならない。これでは全然ラッパーになっていない。MFC のクラスを見るとその中をどう作ればいいのか私でもすぐにわかってしまう。他方 VCL はそれらが隠れていて Visual Basic 程度の知識があれば作れてしまう。また Visual C++ のコントロールのプロパティを見るといかに貧弱かわかる。「ラベルコントロールの色や大きさやフォントはどうやって指定するんじゃ！」これは Visual C++ のプロパティは CreateWindow(Ex) 関数の引数を生成しているだけで、色や大きさやフォントは別の処理が必要である。これがまためんどくさい。
C++ Builder には欠点もある。ランタイムが不要な代わりに exe ファイルが異常に大きくなってしまう。VCL の中身は私にはよくわかっていないが、いくつか余計な処理をしていて邪魔になることもある。本当に効率を追求するなら Visual C++(MFC なし)の方が早い。 よってDeeper File Opener はa! Menu Filerに改名され Visual C++(MFC なし)に書き換えた。また C++ Builder も 3.0 に上げた。
他のソフトもいくつか作成したが、今は Visual Studio 2017 C++(MFC なし)に統一している。

E-mail:CZQ00116@nifty.com

戻る