DOSプログラムは、Win7での起動時に8秒の遅延があります
私のレガシーDOSプログラム（インスタントオフィス）は、Windows 7で起動すると、毎回8秒の遅延に耐えます。
DOSとWin-XPで同じプログラムを何千回も実行すると、すぐに起動します。文字通り1秒未満。
ドライブはほぼ空で、CPU負荷は5％未満で、大量のメモリが使用可能です。スタンドアロンのエアギャップコンピューター。ネットワークはありません。ウイルスはありません。
CMD.exeはすぐに起動します。
ウィンドウが開いてから遅延の時間を計り、PIFが上部に表示されました。
問題はPIFではありません。ディレクトリ（CMDで実行）に移動でき、生の.exeは同じ8秒です。ディレイ。
エミュレーター（仮想マシン）で実行されていることに気付きましたが、8秒？！？
これは、不当に強制された遅延のようです（DOSプログラムから抜け出すためですか？）。
これを引き起こしているアイデアはありますか？
これを診断する方法についてのアイデアはありますか？
この人為的な遅延を回避する方法についてのアイデアはありますか？
ありがとうございました。
PSこの質問ボックスでは、この質問に「DOS」のタグを付けることはできません。しかし、それは別のばかげた問題です。
私は同じ問題を抱えていて、最近解決策を見つけました このサイト （intelvidfix.Zip）。それは私にとって完璧に機能します。
短縮版：
一部のIntelVGAオンボードグラフィックスアダプター（4010U、4340i3および4200Ui5、4600 ...）のBIOSの不具合を修正するパッチで、NTVDMの起動が5〜10秒間遅延し、テキスト出力が遅くなり、フルスクリーンモードでの他のINT10h操作（1文字/秒）。
ロングバージョン：
この混乱の責任は誰にあるのか。インテルまたはマイクロソフト？
興味深いことに、どちらも特定の方法で責任を負っていますが、驚くべきことに、NTVDMの問題は、IntelビデオBIOSのバグを解決するのに有益です。少し紛らわしいですか？詳細については、以下の技術的な詳細をご覧ください。 Microsoftの欠点は、NTVDMの32ビットポートにIN/OUTを実装しないことです。しかし、それが実装されていたとしても、IntelのBIOSは正しく機能せず、さらに多くの問題を引き起こす可能性があります。一方、Intelは、MMIOポートがアクセスできないことを想定していますが、これはNTVDMのようなV86環境では原因ではありません。したがって、これらのMMIOポートを使用しなくても正常に動作しているように見えますが、すべての操作で1秒のタイムアウトで実行されます。したがって、彼らのせいは、不明な理由で失敗した場合に単にスキップするのではなく、毎回1秒間MMIOアクセスを試行することです。実際、この問題は、ビデオBIOSでパッチを適用するのに1バイトしかないチェックルーチンを飛び越えることで解決できます。幸い、BIOSアドレス空間のNTVDMマッピングは、NTVDM拡張DLLを介してメモリにパッチを適用できるため、VGABIOSを再フラッシュする必要はありません。
あなたの提案が実際に意味をなすロバートは、LGA1155チップセットで問題が発生し始めたことです。それは非常に明白でした。
そうです、多分それは現在新世代のプロセッサに組み込まれているIntelGPUと関係があります。何故なの...
ただし、ここではフルスクリーンアプリについてはまったく話していません。単純な理由で、フルスクリーンモードはWindows7から純粋かつ単純に削除されています!!!
したがって、すべてのDOSプログラムは、ウィンドウモードで実行する必要があります。
これは、画面の解像度を変更するときに発生する可能性のあるわずかな（実際には1秒でもない）遅延が発生することは不可能であるため、もはや存在しないことを意味します。
いいえ、ここでは純粋なWindowsディスプレイについて話しています。
簡単に試してみてください。\Windows\System32フォルダにはたくさんのDOSアプリがあります。たとえば、edit.comをクリックして、自分で確認してください。 :)
編集：少なくとも自宅のPCでは、実際には高価なビデオカードを使用しています。
それは現象に何も変更せず、ラグには固定された完全に予測可能な期間があります。
今、あなたは私にそれについて考えさせています、プロセッサ速度はそこで何かを変えます：それは古いPentium4よりもi5で短いです...
したがって、おそらくどこかで、おそらくNTVDMを実行しているときに、何らかのデータ処理が必要になります。
自分で簡単に確認できるもう1つの機能は、ラグが1回だけ発生することです。
私が説明している：
- シェルを起動します：ラグはまったくありません
- 任意のDOSプログラムを実行します：lag
- プログラムを終了し、再度実行します（またはその他）：ラグはまったくありません。
これは、ディスプレイとはまったく関係がなく、NTVDMを初めて呼び出すこと（そしておそらく作業環境を設定すること）に関係していることを意味します。
新しいチップセットとの唯一の違いは、それが直前であった場所であり、突然数秒かかりました。
実際には、16ビットアプリの使用を意図的に排除しようとしているのではないかと思いますが、VistaではなくWindows 7以降でのみ発生するため、ここでは非常に複雑ですXP（ドライバーを見つけることができれば、通常はグラフィックスを除いて実行できますが、IntelでRealtekやその他のメーカーではない場合はネットワークドライバーもあります）、そしてもちろんLinuxでは...
...したがって、Intelを非難することはできませんが、Microsoftが最近のバージョンのWindows（同じラグを備えた32ビットのWindows 10を含む）でNTVDMでハードウェアを使用している方法です。
あなたは間違ったことを想定しています。誰も自分で見てみなかったのには驚きました。
これがどのように機能するかです、それで多分物事はより正確に述べられるでしょう：
明らかに32ビットバージョンです。 NTVDMがすべての64ビットWindowsバージョンから削除されているため、64ビットバージョンは16ビットプログラムを起動できません。
エミュレーターを使用する場合、ラグはまったくありません。それはプログラム自体とは何の関係もありません。Windowsやシェルなどからプログラムを起動するときの、恣意的でまったく理解できない遅延にすぎません。
編集など、Windows自体に付属しているMicrosoftアプリを起動して、自分で簡単に確認できます。
ちなみに、DOSプログラムを起動するとすぐに、キーボードのローカリゼーションも失われます。
この簡単なテストを行うだけです：
コマンドプロンプトを起動します
edit->くそー5秒（またはそれくらい）の遅れを入力すると、古典的なDOSテキストエディタが開きます
何でも入力->キーボードはUSレイアウトになりました。
それについては、autoexec.ntにlh kb16を追加すると問題が解決しますが、AltGrキーが無効になっているため、「\」、「@」などを入力できません。ALT+ ASCIIコード... Windows Vistaでは正しく機能した（XPでは必要なかった）ことに注意してください。Windows7以降、MSは障害のあるキーボードテーブルを提供し、修正しませんでした。
私たちの懸念に戻る：
非常に単純な理由で、画面の解像度や周波数などとは何の関係もありません。フルスクリーンモードはもう存在しません。全画面表示でDOSプログラムを起動することは絶対にできません。それらは常にウィンドウ化する必要があります。したがって、明らかに、Windowsデスクトップの表示には何の変更もありません（これも書く前に簡単に確認できます！）
ただし、Intelベースのグラフィックスに関するアイデアは深刻なヒントになる可能性があります。
実際のところ、LGA 775マザーボードまでは簡単に機能し、LGA1055チップセットで最初に遅れが生じました。私はそれをはっきりと見ることができました（はい、私の顧客はクリッパーで書かれたプログラムを使用しています。それでは何ですか？彼らは完璧に仕事をしています）。
それで、それは最新のマザーボードチップセットとインテルプロセッサの統合されたビデオ処理に接続されていますか？
どのプロセッサでも（最も弱いCeleronから最も速いi7まで）まったく同じように動作し、LGA 775チップセット以前を使用しているマザーボードでは、プロセッサに関係なく、アドオンの有無にかかわらず、ラグがないことを確認できます。ビデオカード。
少なくとも、これらは事実です。
今、治療法について...私はまだ調査中です。 ：p
今のところ、私が見つけた最も満足のいくソリューションはvDosエミュレーターです。 DosBoxとは異なり、マルチユーザーアプリケーションのファイル共有を正しく管理します（ただし、この場合は無料ではありません）。 WMWareも簡単に動作しますが、インストールは重くなります（vDosはほとんどインストールする必要がありません。実際には、DosBoxよりもはるかに高速で使いやすいです）。
上で述べたように、vDosを介してDOSプログラムを起動すると、すぐに起動できます。遅延はまったくありません。もちろん、これは主に64ビットのWindowsを対象としていますが、32ビットのWindowsでDOSプログラムを使用する方が便利です。これは、最初からひどい遅れを取り除くためです。
実用面では、マルチユーザーのお客様は、実際にはsshでDosemuを実行しているLinuxサーバーに接続されたPuTTYを介して作業します。少なくとも、このセットアップにはキーボードやディスプレイの問題はありません（ディスプレイの問題については、MicrosoftはWindowsにCHCPを追加していますが、すべてのDOSプログラムは常に標準の437コードページを使用しているため、まったく意味がありません。 。その結果、一部のセミグラフィック文字は、代わりに派手なエキゾチックなアクセント付き文字を表示します）。
もちろん、奇妙な遅れなしにネイティブWindowsでDOSプログラムを起動できることは、より満足のいくものです。これとひどいキーボード翻訳のバグ...それはVistaで問題なく動作したので、Vistaファイルを最新のWindowsバージョンに挿入できるかどうか疑問に思っています...私はまだそれらを特定する必要があります。
一般的に、dosのサポートはXP（98で動作した少数のプログラムを実行しません）以来、徐々にカットされました。Windows7でそれらを起動できたことは、すでに小さな奇跡です。 。それを念頭に置いて、DOSBoxでさえWindowsネイティブの「エミュレーション」よりも速くこれらのプログラムを実行できたとしても、まったく驚くことではありません。
実際にはPrusswan、DosBoxはこれらのプログラムを非常に遅く実行します。
私の顧客がこれらのプログラムをスタンドアロンとして実行するためにPCを要求しているとき、私はそれらに32ビットOSをインストールします。それだけです。
唯一の欠点は、ローカライズされたキーボードドライバー（autoexec.iniにkb16を追加する必要があります）が台無しになっていることです。AltGrキーが無効になり、拡張文字が使用できなくなります（つまり、 "@"、 "\"たとえば、フランス語の「＃」など。ユーザーはAltキーを押しながら、ASCIIコード！）と入力する必要があります。
それ以外は、ネイティブWindowsでこれらのプログラムを実行すると最速のエクスペリエンスが得られます（Windows 10でNTVDMを再度有効にする必要があります。これには設定があります）。
ただし、vDosは非常に優れた代替手段です。
XPModeを使用すると速度が少し遅くなることに同意しますが、それも非常に満足のいくものでした。残念ながら、XPModeがWindows10から削除されたことを後悔しています。
そこにはDOSアプリだけでなく、一般的な16ビットのWindowsアプリも含まれていました。私はGraphicWorks 4を何十年も使用しています（不思議に思うかもしれませんが、ライセンスを購入しました）。i7+ 16を取得するために64ビットでWindows7を愚かにインストールしたため、自宅ではもう使用できません。 GB RAM + 10 Gbps SSDフルパワー、そして私はそれをさらに愚かにWindows 10に更新しました...だから今、家で簡単な技術的なスケッチはもうありません。:(
とにかく、64ビットWindows（およびラグが本当にあなたを混乱させる場合は32ビットWindows）でのDOSアプリの現在の最良の解決策はおそらくvDosです。
しかし、この奇妙な遅れについての理由、そしてうまくいけば治療法については疑問が残ります...