2007年に死んだはずの「FoxPro」がまさかの復活！伝説のDBはなぜ今蘇ったのか？

Microsoftが2007年にサポートを終了し、完全に過去の遺物となったはずの「FoxPro」が、なんと現代に復活しました。かつて一世を風靡したこのデータベース環境が、どのような形で息を吹き返したのか。その詳細な動向を追っていきます。

参入障壁が低くて開発者の生産性が高く、結果として生まれるアプリケーションが「独自の業務プロセスに極めて適合した」オーダーメイドなものになるのは本当に素晴らしい。でも、こうしたシステムが基盤プラットフォームの能力を超えてしまうと本当に悲惨だよね。

今どきのイケてないオーバーレイネットワーク技術が標準の環境で、「ネットワークドライブ」上のDBFファイルにアクセスしようとする企業を想像するだけでゾッとする。シームレスなリモートアクセスは、まさにVisual FoxProアプリが苦手とするところだしね。

見た目はクールだけど、実際にこれで作られたアプリを運用したくはないな。クライアント/サーバー型のデータベースを透過的に組み込めたら面白いんだけど。

もう何年も経つのにMicrosoft Accessはまだ現役だし、たった3年前に32bit版でLarge Address Aware (LAA) サポートまで追加されたんだよね！厳密に言えば僕の最初のソフトウェアの仕事は数週間Microsoft AccessでVBAを書くことだったけど、おそらく今でも使われているはず（代替ソフトもなければ、安価に移行する方法もないから）。

おっ、最近これについて言及したばかりだよ！ちょっとした自慢なんだけど、前の職場かその前でVisual FoxProのデータベースファイルをPostgreSQLに移行するためのツール[0]を書いたことがあるんだ。しばらくの間、古いVFPアプリでデータ入力が必要な人たちのためにcronジョブとして動かしながら、他のメンバーはPostgreSQLをバックエンドにしたウェブアプリで高速なレポートを参照できるようにしてた。綺麗とは言えないけど素晴らしい働きをしてくれて、あの古臭いスタックから脱却する手助けになったよ。

[0]https://github.com/kstrauser/pgdbf (https://github.com/kstrauser/pgdbf)

2006年に医師のオフィスで仕事をしたとき、主任医師がVisual FoxProを使って患者追跡システムを無理やり作り上げてたんだ。あれはまさに怪物で、ネットワークドライブ越しに使っていると、複数の人が同じレコードを変更するたびに（たいてい医師と受付スタッフが同時に操作してた）、ファイルロックや競合が多発してたよ。

結局、.NET WinFormsとASP.NETのRPC呼び出しを使ったまともなクライアント/サーバーアーキテクチャに移行するよう説得したんだ。すると全ての問題が解決したし、ラボの検査フォームをXMLで作ることで、スタッフが自分の好きなようにX/Y座標を動かして画面をカスタマイズできるようにまでした。自分でも想定していなかった機能だったけど、医師が技術の中身を理解して勝手に使いこなしてくれた（幸いビジネスロジックやセキュリティロジックはサーバー側にあったから、悪意ある操作をされても自分のローカルにあるアプリのコピーが壊れるだけだったけどね）。

FoxProをどんな形であれ復活させることに対する僕の懸念はこれだ。Database Container (DBC) の設計に巨大なセキュリティホールがあるんだよ。DBCが役立つためには全ユーザーに対して読み書き可能でなければならない（権限管理の仕組みがない）。DBCには、FoxProランタイムからWin32コールを含むあらゆるFoxProコードを実行できるストアドプロシージャがある。そのストアドプロシージャは「メモ」フィールドにプレーンテキストで保存されている。何が言いたいか分かるよね？少しの技術知識があれば、誰でもINSERTトリガーを好きなように改変できてしまうんだ。

僕の推奨は、DBF/DBCファイルをすぐに捨てて、さっさと何らかのSQL DBに移行することだ。ソースコードがあるなら、ODBCかOLE DBを使ってサーバーに向けるべきだよ。

ソース：僕がFoxチームにいた20年以上前にそのバグを報告したんだ。データベースエンジンの仕組みを大幅に書き直さない限り、修正されることはなかったよ。

MicrosoftはFoxProを葬り去ったかもしれないけど、Windows 11ですらmoricons.dllの中にアイコンが残っている。おそらくMicrosoftがリリースするあらゆるWindowsのバージョンで、永遠に生き続けるんだろうね。

懐かしいな。思春期の頃、dBaseやFox製品が僕の最初の有償ソフトウェア開発の仕事だった。子供にすら驚くほど親しみやすかったんだよね。

本来はコンピューターデスクを組み立てたり、ネットワーク化されたUnixやPCソフトウェアをインストールしたりするだけの役割だったんだけど、母親の勤務先の引退した海兵隊員が僕に才能を見出してくれた。「おい、小僧」と彼は言って、既存のdBaseの車両保険データベースをより多くの車両に対応できるように修正しろと言い放った。C言語のデータベースライブラリとMicrosoft Cのマニュアルを渡されて、「自分で考えろ」と。会計システムの移行も担当した。ターゲットスキーマのサンプルDBFを渡されて、レガシーなミニコンピューターからフルダンプを生成する方法と、Emacsというエディタを使ってインポート用に整形する方法を教えてもらった。「自分でスキーママッピングを考えてやり遂げろ」ってね。自分でも古いdBase製品やFox製品を家用に買って、もう少し複雑なシステムを組む練習もしたよ。

（その後も働き続け、雇用主が「何かを解明する」ことを求めてくれる期間があった。 mentorのおかげで、自分で解決できると周りも喜んでくれた。でも、正式な学位を取るためにブランクを作った後で驚いたのは、仕事の面接がいきなりLeetcodeのような形式に変わっていたことだ。彼らは自分で考えて解決してほしいわけじゃなくて、大企業が承認したルール通りの「リハーサルされた儀式」を求めていた。あの海兵隊員は、そんな酷い緑色の本[面接対策本]を打ち負かすような本なんて書いてなかったんだよね :) ）

ああ、ノスタルジーだ。dbase、clipper、clarion、foxbase、delphi...。VFPが大好きだったな。言語そのものというより、スクリーンデザイナーやDBブラウザ、SQLクエリといったツールが好きだった。あのパワーとユーザー体験が、当時の.NETという「まがいもの」のためにゴミ箱へ捨てられたんだよ。

VB.net、C#、F#まで学んで、愛したVFPを超える要素があるか確かめたけど、どれも違った。裏切られた気分で、25年前に銀河の彼方へ旅立つことを決めて二度と振り返らなかったよ（当時はexeとシングルユーザーアプリが主流で、それからマルチユーザーと外部DBストレージが来て、ウェブが支配した時代だった）。

これは期待できそうだね。試してみるつもりだよ。AIにフォークを頼めるなら、言語を少しモダンに変えてみようかな（今のままだとパンチカードに書かれたCOBOLみたいに見えるし）。

Visual FoxProは32bitプログラムであり、それは見た目以上に決定的な意味を持つ。

誰かモデルの何がこの構文を引き起こすのか研究した人はいる？事実をぶちまけてから後でその重要性を述べるというのは、アーキテクチャ上の何らかの結果なのかな？

クソッ、子供の頃に父の本棚にあったFoxProの本を思い出して懐かしい気分になったよ。ありがとう、ネクロマンサー（死霊使い）さん。