Microsoftが2007年に葬ったFoxProが、64ビットで蘇る
Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived
FoxDev Studioは、Visual FoxPro 9のプロジェクトやフォーム、テーブルをそのまま開いて実行できるIDE。書き換えも変換も不要で、既存のアプリケーションが現代のマシンで動く。ランタイムはRustとWebAssemblyでゼロから作られ、32ビットの壁を超えて64ビット化。古い.fllライブラリもブリッジ経由で利用可能。FoxScriptによる拡張で、HTTPサーバー機能も同じ言語で書ける。
Visual FoxProはバージョン9、32ビットで止まった。これは同じ言語を、2007年から凍結されていない基盤の上に再構築したものだ。
HNでの議論
250- mikestew
FoxProをどんな形であれ復活させることについて、私が抱いている問題はこれだ。Database Container（DBC）の設計には巨大なセキュリティホールがある。DBCが役立つためには、全ユーザーに対して読み書き可能でなければならない（権限スキームが存在しない）。DBCにはストアドプロシージャがあり、FoxProランタイムからのWin32呼び出しを含む任意のFoxProコードを実行できる。ストアドプロシージャは「memo」フィールドにプレーンテキストで保存されている。どこに向かっているか分かるだろう？少し技術的知識があれば、INSERTトリガーを好きなように書き換えられる。追記：DBはファイルシステム上の単なるファイルなので、テキストエディタを使って変更でき、FoxProランタイムのチェックを回避できる。FoxProはそこにあるものをただ実行するだけだ。
私の推奨は、DBF/DBCファイルを捨てて、早急に何らかのSQL DBに移行することだ。ソースコードがあるなら、ODBCかOLE DBを使ってサーバーを指せばいい。
出典：20年以上前にFoxチームで働いていたときにこのバグを報告した。いいえ、DBエンジンの動作の大部分を書き直さない限り修正されることはなかっただろう。
- progmetaldev
2006年に医師のオフィスで働いていたが、主任医師がVisual FoxProを使って患者追跡システムを寄せ集めていた。それは怪物で、ネットワークドライブ経由で使うとあらゆるファイルロックや、複数人が同じレコードを変更する問題（通常は医師と、患者のチェックアウト時のフロントスタッフ）が発生した。
最終的に医師を説得して、.NET WinFormsとASP.NET RPC呼び出しを使った適切なクライアント/サーバーアーキテクチャに移行させた。すべての問題が消え、スタッフがインターフェースを編集して、自分にとって最も重要なものをアプリケーションの上部に設定できるようにもなった。検査フォームをXMLで構築し、X/Y座標を好きな位置に移動できるようにしたのだ。それは私が考えもしなかった機能で、ただ医師がテクノロジーを調べて仕組みを理解しただけだった（幸いにもビジネスロジックとセキュリティロジックはサーバー側にあったので、悪意のある行為者は自分のローカルコピーのアプリを破壊することしかできなかった）。
- networkOne
なんてこった、過去からの爆風だ。プログラマーにとって栄光の時代だった…あらゆるビジネスが日々の簡単な雑用のためにデータベースを必要とし、コーディングは信じられないほど簡単で（ただのCRUD処理の山）、顧客への影響は劇的だった…だから法外な金額を請求できた。
カナダの不動産鑑定市場向けに、FoxProで簡単なCRUDアプリを書いた。作成に約1ヶ月のパートタイムを要し、初年度は299ドルで300ライセンス売れた。
ああ、もっと単純だった時代の思い出よ。
- neilv
フラッシュバック。思春期の頃、dBaseとFox製品が私の最初の有償ソフトウェア開発で、子供にさえ驚くほど親しみやすかった。
私はコンピュータ家具の組み立てを手伝い、場合によってはネットワーク化されたUnixやPCソフトウェアをインストールするだけの予定だった。しかし、母が働いていた引退した海兵隊員は私に可能性を感じていた。「おい、坊主」と彼は言った。「このdBaseの車両保険データベースをより多くの車両をサポートするように修正する必要がある。何とかしろ。これがCデータベースライブラリとMicrosoft Cのマニュアルだ、評価中だ。何とかしろ。会計システム間の移行が必要だ。これがターゲットスキーマのサンプル.DBFだ、レガシーミニコンピュータから完全なダンプを生成する方法はこうだ、Emacsというエディタを使ってインポート用にダンプをクリーンアップしろ、スキーママッピングを理解したらな。何とかしろ。」私はまた、古いdBase製品とFox製品を自宅用に購入し、いくつか凝ったシステムを構築する方法を独学で身につけた。
（その後も働き続け、すべての雇用主が私に何かを解決するよう求めたり、私がすぐに解決すると好意的に驚いた時期があった。それは「自分で解決しろ」というメンターたちの形成的影響のおかげだ。その後、遅ればせながら正式な学位を取得するために休憩し、その休憩後に驚いたのは、就職面接が突然Leetcodeのようになり、彼らは私に解決してほしいのではなく、大企業が認めたルールに従ったリハーサル済みの儀式的パフォーマンスを求めているようだった。どうやらあの海兵隊員はそれに対抗する本を書いていなかったようだ[…]
- EvanAnderson
参入障壁の低さ、高い開発者生産性、そして結果として生まれるアプリケーションのオーダーメイドで「独自のビジネスプロセスに高度に適合する」性質は本当に素晴らしい。しかし、これらのシステムの一つが基盤プラットフォームの能力を超えて成長すると、本当に厄介だ。
今日の標準である様々な質の悪いオーバーレイネットワーク技術を介して、企業が「ネットワークドライブ」上のDBFファイルにアクセスしようとするのを考えると震えがくる。アプリケーションへのシームレスなリモートアクセスは、まさにVisual FoxProアプリが失敗するレシピだ。
見た目はクールだが、実際にそれで作られたアプリの周りで働きたくはない。クライアント/サーバーデータベースを透過的に押し込むことができたらクールだろう。
- kstrauser
おい、最近これについて言及する機会があった！私の奇妙な自慢の一つは、数社前の雇用主で、移行の一環としてVisual FoxProデータベースファイルをPostgreSQLに変換するこの小さなツール[0]を書いたことだ。しばらくの間、人々が古いVFPアプリでデータ入力できるようにしつつ、他の人々がPostgresバックエンドのWebアプリで高速レポートを実行できるように、cronジョブとして実行する必要があった。美しくはなかったが、うまく機能し、その古代のスタックから抜け出すのに役立った。
- Hasz
はは、アプリモダナイゼーションに反対するセールスコールで、まさにこの例を使ったよ。時には、20ドルとガムテープレベルの予算で、物事が動き続けるだけでいいんだ。
私の提案は、間にプロキシレイヤーを置き、k8sのようなもので実行し、主にLLMが書いて、FoxProへのクエリに対する安全なインターフェースを提供するというものだった。レート制限、クエリ解析、REST、その他必要なビジネスロジックも全部ね。
それがまだ存在していることに愕然とするが、文字通り世界全体を動かしている、もっと古い、もっと始原的なものもあるんだよな :)
- NoelJacob
AIを使って書くのはやめてくれ、頭痛がする。自分で書ける簡単な2行の文でいいし、面倒なら口述筆記でもいい。