すでに提案されているように、アプリを仮想化環境で維持するだけでなく、最初にすべきことは、コードが FAT-16 を必要とする理由を突き止めることです。
アプリ (またはそのランタイム) が特に悪質な場合、FAT-16 要件は、オペレーティング システムをバイパスして直接ディスク I/O を実行しようとしていることが原因である可能性があります。BASIC コード自体がその特定のスタントを実行しようとしている場合は、I/O ルーチンで多数の CALL、PEEK、POKE、または時折の IN および OUT ステートメントを確認する必要があります。ランタイムが何に対応しているかを判断するのはより困難です。それが Microsoft、DOS ベースでそれほど古くないもの (GWBASIC や QuickBASIC/PDS など)、または Windows ベースの場合は問題ありません。
いずれにせよ、アプリまたはランタイムのいずれかが直接ディスク I/O を試みている場合は、負けです。大規模な書き換えのようなコード変更を行わずに最新の OS で動作させることはほとんど不可能です。
アプリが入力と出力に通常の BASIC 機能を使用しており (例: OPEN "file" FOR any AS #1)、ランタイムも通常の OS インターフェイスを使用している場合、FAT-16 でのみ動作する最も可能性の高い理由は、長いファイル名によって完全に混乱します。
最初に試すことは、アプリを短い名前のディレクトリ (例: c:\myapp) に配置し、次に何が起こるかを確認することです。それ以外の場合は、BASIC コードをステップ実行することで、何が起こっているかを把握できるはずです (デバッガーがランタイム環境の一部であると仮定して)。
アプリが実行されている正確なインタープリター/コンパイラーに関する詳細情報がなければ、質問に詳細に回答することはできません。これまでの回答が役に立たなかった場合は、質問を編集してこの情報を含めることをお勧めします。