問題タブ [bios]

Win32 で WMI API を使用せずに BIOS シリアル番号を取得するにはどうすればよいですか? WMI 以外の方法で、Windows ゲスト アカウントでの WMI 呼び出しがアクセス拒否として返されるようにする必要があります。

私は学習目的で小さなブートローダーに取り組んでいます。BIOS 割り込み呼び出しに必要な (無料の) スタック サイズに関する仕様/情報はありますか?

次のような文字を画面に印刷する機能があります。

そして、文字254を10進数で印刷したいのですが、に保存されたものを使用する必要がありますconst char*。print(0x0F, 0, 0, 0xFE);キャストせずにポインタのエラーが発生するため、試すことができません。どうすればよいですか？

BIOSオプション（POST後）になるプログラムを書こうとしています。アプリケーションがテキスト ベースではなく、優れた GUI を備えていることを望みます (これには複数の理由があり、ローカリゼーションもその 1 つです)。

私の問題は、BIOS にフラッシュできるアプリケーションのサイズに制約があることです。

Windows API を使用して GUI を開発できるように、MASM32 を使用してハードディスク上の dll に「リンク」することは可能ですか?

または、最終的な実行可能ファイルにリンクできる GUI を作成するために利用できる API はありますか? (最終的なプログラム実行可能ファイルに対する 60K サイズの制約)

事前に感謝します。

MASM32 を使用すると、実行可能ファイルに埋め込まれたバイナリ ファイルに格納されているビットマップをコンソールに表示できますか?

誰でも方法を教えてもらえますか?

補遺: ここでは本格的な GUI について話しているわけではありません。文字のビットマップを画面に表示する機能だけです。それらは、実行可能ファイルにリンクするファイルに 8x8 のバイナリ イメージとして保存されます。

Linux用のCに、BIOSVerisonDigitalIDなどのGPU情報を取得するためのライブラリはありますか...

最新のOSのBIOSの機能は何ですか？起動後も使用されていますか？そして、ある種のBIOS APIはありますか？

「アドレス0x500はBIOSによって使用される最後のアドレスです」はウィキペディアのものです -

「00000000-000003FFリアルモードIVT（割り込みベクトルテーブル）」は、BIOSメモリマップに関するosdev.orgの記事に記載されています。

では、NASMが.comファイルのスタックポインタを0x3FFに配置し、命令ポインタが0x7C00で始まる理由を教えてください。私にとって、SPの最も直感的な場所は、0x7C00のすぐ下です。

起動可能なCDでソフトウェアを配布したい場合、BIOSがCDからの起動でセットアップされていなくても、（Windowsから）マシンを強制的にCD OSで再起動する方法はありますか？

質問:次のように、ネットワーク化されたクライアントごとに一意の ID を考え出す必要があります。

• クライアント ソフトウェアがターゲット コンピューターにインストールされると、それ (ID) は持続する必要があり、ソフトウェアが同じコンピューターと同じ OS インストールに再インストールされた場合でも持続する必要があります。
• ハードウェア構成がほとんどの方法で変更された場合 (マザーボードの変更を除く)、変更しないでください。
• クライアント ソフトウェアがインストールされたハード ドライブが、同一のハードウェア構成 (または可能な限り類似した構成) を持つ別のコンピューターに複製される場合、クライアント ソフトウェアはその変更を認識する必要があります。

少しの説明と裏話：

この質問は基本的に古くからの質問であり、ソフトウェアのコピー防止のトピックにも触れています。その分野で使用されているメカニズムのいくつかがここで言及されているためです。この時点で、コピー防止スキームを探しているわけではないことを明確にしておく必要があります。読んでください。:)

私は、ローカル ネットワークで動作するはずのクライアント サーバー ソフトウェアに取り組んでいます。私が解決しなければならない問題の 1 つは、ネットワーク内の一意の各クライアントを識別することです (それほど大きな問題ではありません)。これにより、特定の属性をすべての特定のクライアントに適用し、特定のクライアントの展開ライフタイム中にそれらの属性を保持および適用できます。クライアント。

解決策を探していたときに、次のことに気付きました。

• Windows アクティベーション システムは、ハードウェアの変更に非常に敏感なある種の重いフィンガープリンティング メカニズムを使用します。
• ディスク イメージング ソフトウェアは、すべてのボリューム ID (フォーマット時に各パーティションに結び付けられる) と、インストール プロセス中、最初の実行中、またはその他の方法で一意に生成されたカスタム ID に沿ってコピーします。ハードドライブ上にあるため、2 つを混同するのは非常に簡単です。

この種の問題に対する明らかな選択は、BIOS 識別子を見つけることです (ただし、これが同一のマザーボード モデルで一意であるかどうかは 100% 確実ではありません)。 、そしてそれは変更できません（少なくとも、ユーザー空間プログラムを使用することによってはできません）。それ以外はすべて、信頼性が低い (MAC の複製など) か、要求が高すぎる (構成の変更に敏感すぎるという点で) 失敗します。

私が尋ねたい副次的な質問は、私はそれを正しく、アーキテクチャ的に行っていますか? おそらく、私が達成しなければならないタスクのためのより良いツールがあるでしょう...

私が念頭に置いていた別のアプローチは、サーバーが接続されたクライアント ID の内部ルックアップ テーブルを維持するハンドシェイク メカニズムに似たものです (完全にソフトウェア ベースで、任意の時点で一意ではない場合もあります)。接続時に重複した ID が提供された場合、ハンドシェイク中に別の ID を考え出します。残念ながら、このアプローチは、有効期間中に属性を特定のクライアントに結び付けるという要件の 1 つにはうまく対応できません。