問題タブ [winapi]

フレームワークは、OS の速度と難読化を犠牲にしてコーディングを簡素化します。ムーアの法則が成立したことで、フレームワークからの移行があると思いますか?

Vista が目立った成功を収められなかった理由の 1 つは、XP よりも実行速度がはるかに遅かったことであり、コンピューターの速度が過去ほど大幅に向上していなかったため、この変更は一歩後退したように見えた.

何年もの間、CPU の速度はソフトウェアの速度を上回っていたため、OS の難読化と肥大化の層を追加した新しいフレームワークはほとんど害を及ぼしませんでした。Windows 95 が今日のハードウェアでどれほど高速に動作するか想像してみてください (メモリを少し調整した場合)。Win2K と WinXP は大きな改善点であり、コンピューターが高速になったために速度が遅くなっても問題はありませんでした。

しかし、何年も前に、MS ファウンデーション クラスで記述されたプログラムは、API に直接記述された同じことを行うコードほど鮮明に見えないことに気付きました。.Net などのこれらのフレームワークの急増は、この状況を悪化させるだけなので、「C」で直接 Win32 API (または他の OS の同等のもの) にコードを記述できることを発見する可能性はありますか?書くのに時間がかかったとしても、強力な競争上の優位性になりますか? それとも、開発期間が長くなるというトレードオフは、それだけの価値がないのでしょうか?

理想的には、リーダーはネイティブC++プログラムをOpenClipboard（）ブロックを含むVisualStudio2008にアップグレードしました。OpenClipboard（）から正常なリターンコードを取得した直後にブレークポイントを設定して、コードをステップ実行してみませんか。インターネットによると、それはあなたのシステムで動作するかもしれませんが、もちろん、私のものではなく、試してくれてありがとう。

たとえば（（OpenClipboard 1418 vc6））をグーグルで検索すると、「GetClipboardDataはデバッガーで失敗します」や「VC ++ 6ではエラーは発生しませんが、VC++2005ではエラーが発生します」などの記事が見つかります。実用的には、問題は解決しました-そのようなコード内にブレークポイントを設定することはできません。クリップボードの操作が完了した後、情報をリスしてブレークポイントを設定する必要があります。エラー1418は「スレッドでクリップボードが開いていません」ですが、VS.NETを使用しない限り、またはクリップボード-オープン-クローズ-ブロックの外側にブレークポイントを保持する場合は、正常に機能します。

VS.NETデバッガーの正確な問題が何であるかを知ったほうがよいと思います。

C ++の人間である私は、dot-Netを実行するときに、スレッドの観点から考える必要がないことをぼんやりと認識しています。とにかく、実際に問題が、ネイティブC ++コードをシングルステップで実行したときに、dot-Netデバッガーがスレッド情報に微妙に干渉していることであるかどうかにかかわらず、実際に何が起こっているのかについての第一人者品質の説明は見つかりませんでした。

システムに関して：XP-proによると、約1年前、2つのデュアルコアXeon、4つのCPU。XP-SP2-32ビットのvc6でシングルステップでコードをデバッグし終えたところです。だから私はコードがvc6の下でかなりうまくいったことを知っています。ただし、10メガバイトのCF_TEXTでテストしたところ、例外が発生しました。XP-x64のより良い例外モデルの下でデバッグを試してみようと思いました。

visual-studio-2008で再コンパイルしたところ、コードをシングルステップにすることができませんでした。OpenClipboardは機能しましたが、EnumClipboardFormats（）は機能せず、シングルステップでは何も機能しませんでした。ただし、コードの完全なブロックの下にブレークポイントを設定すると、すべてが正常に機能しました。そして、はいvc2008は、szBufの周りのピンポイント診断のスタックフレームの破損を引き起こしました。vc2008については好きなことがたくさんあります。これがどういうわけか単なるクリップボードの問題であるとしたら、スレッドコンテキストの問題がdot-Net-debuggerに起因するかどうかにかかわらず、何かをステップスルーすることを心配せざるを得ないと感じることなく、それは素晴らしいことです。

アプリケーションサーバーとそのクライアント側ライブラリをC++で実装しているときに、Windowsのサーバーシャ​​ットダウン時にクライアントプロセスを停止するためのクリーンで信頼性の高い方法を見つけるのに苦労しています。

サーバーとそのクライアントが同じユーザーの下で実行されていると仮定すると、要件は次のとおりです。

• このソリューションは、次の場合に機能するはずです。
  • クライアントはそれぞれ、コンソールまたはGUIのいずれかを備えている場合があります。
  • ユーザーには特権がない可能性があります。
  • クライアントは応答しなくなるか、応答しなくなる可能性があります（無限ループ、デッドロック）。
  • クライアントはサーバーの子である場合とそうでない場合があります（直接または間接）。
• クライアント側の欠陥によって防止されない限り、クライアントはクリーンに終了する機会（リソースを解放し、一部のデータをディスクに同期する...）と、そうするための妥当な時間を許可されるものとします。
• すべてのクライアントリターンコードは、シャットダウン手順中にサーバーで利用できるようにする必要があります（可能な場合）。
• サーバーは、すべてのクライアントがなくなるまで待機する必要があります。

この編集の時点で、以下の回答の大部分は、サーバーとそのクライアント間で共有メモリ（または別のIPCメカニズム）を使用してシャットダウン命令とクライアントステータスを伝達することを推奨しています。これらのソリューションは機能しますが、クライアントがライブラリを正常に初期化する必要があります。

私が言わなかったことは、サーバーはクライアントを起動するためにも使用され、場合によってはクライアントライブラリをまったく使用しない他のプログラム/スクリプトも使用されるということです。サーバーとクライアント間の適切な通信に依存しないソリューションの方が優れています（可能な場合）。

しばらく前に、次のことを行うCスニペット（MSDNで私が信じている）に出くわしました。

1. シャットダウンするプロセスでCreateRemoteThreadを介してスレッドを開始します。
2. そのスレッドにExitProcessを直接呼び出させました。

残念ながら、今探しているのですが、見つけることができず、検索結果は、このトリックがVistaでは機能しなくなったことを示唆しているようです。これに関する専門家の意見はありますか？

レガシー アプリケーションの 1 つはPostThreadMessage()スレッド間通信に大きく依存しているため、レジストリの USERPostMessageLimit を通常の 10.000 を超えて (途中で) 増やしました。

ただし、MSDN のドキュメントには、「この制限は十分に大きくする必要があります。アプリケーションが制限を超える場合は、システム リソースを大量に消費しないように再設計する必要があります。」と記載されています。[ 1 ]

あまりにも多くのシステム リソースがどのように消費されるかについて、誰か教えてもらえますか? システムリソースとは正確には何ですか? アプリケーションによるシステム リソースの使用状況を何らかの方法で監視できますか? このアプリケーションを再設計するのに時間と労力を費やす価値があるかどうかを判断するには、どのような情報でも非常に役立ちます。

商用アプリケーションの 1 つ (Delphi で作成された Win32) で、全文検索を実装したいと考えています。アプリケーションは、テキストとして直接認識できない何らかの種類のバイナリ形式でユーザー データを格納しています。

理想的には、インプロセス ソリューション (DLL で問題ありません) または TCP 経由でアクセスできるローカル サーバー (できれば) を見つけたいと考えています。この API を使用すると、サーバーにテキスト情報を (その元のバイナリ BLOB を表すメタデータと共に) 送信できる必要があり、もちろん、少なくとも論理演算子のサポートを最小限に抑えて全文検索を実行できる必要があります。および部分文字列検索。Unicode サポートが必要です。

スタック オーバーフロー ( What are some Search Servers out there? )で検索エンジンの広範なリストを見つけましたが、どのエンジンが自分のニーズを満たすことができるのかよくわかりません。それぞれのテストに 1 日か 2 日を費やす前に、The Collective に意見を求めることを考えました。

助言がありますか？

Windowsでは、Unixでは発生したことのない問題が発生します。これが、スレッドを1ミリ秒未満スリープさせる方法です。Unixでは、通常、ニーズに合わせていくつかの選択肢（sleep、usleep、nanosleep）があります。ただし、Windowsでは、ミリ秒単位の粒度のスリープしかありません。

Unixでは、selectシステムコールを使用してマイクロ秒のスリープを作成できます。これは非常に簡単です。

どうすればWindowsで同じことを達成できますか？

リッチエディットコントロールのドキュメントは、見た目と同じくらい悪い（間違っていますか？）ですか？現在、リッチエディットコントロールを表示するために、手動でLoadLibrary（ "riched20.dll"）を呼び出しています。Rich Editのドキュメントは、RichEditコントロールを使用するための最初のコードサンプルでこれを十分に示していません。

InitCommonControlsEx（）を呼び出して視覚的なスタイルを追加する方法について説明していますが、渡すフラグについては言及していません。

リッチエディットコントロールをロードするより良い方法はありますか？

http://msdn.microsoft.com/en-us/library/bb787877(VS.85).aspx

これが私がそれを機能させるために書くことができる唯一のコードです：

Win32 API を使用して USB ドライブを取り外すにはどうすればよいですか? 私は組み込みシステムで多くの作業を行っていますが、そのうちの 1 つで、自分のプログラムを USB スティックにコピーしてターゲット ハードウェアに挿入する必要があります。

私は主にコンソールで作業しているので、マウスを使って小さなタスクバーのアイコンを 1 日に何百回もクリックするのは好きではありません。

Makefile に入れることができるように、まさにそれを行う小さなプログラムを書きたいと思っていますが、同じことを行う API 呼び出しは見つかりませんでした。

何か案は？

コンパイラ、オプティマイザ、およびインデックス作成テクノロジについて詳しく知るために、C＃でおもちゃのデータベースを構築しています。

ページをバッファプールに取り込むための（少なくとも読み取り）要求間で最大の並列処理を維持したいのですが、.NETでこれを実現するための最善の方法について混乱しています。

ここにいくつかのオプションと私がそれぞれに遭遇した問題があります：

1. 使用法System.IO.FileStreamとBeginRead方法

   ただし、ファイル内の位置はの引数ではなく、（メソッドを介して設定された）BeginReadのプロパティであるため、一度に1つのリクエストしか発行できず、その間ストリームをロックする必要があります。（または、私は？との間にのみロックを保持し、電話をかける前にロックを解除した場合、ドキュメントは不明確です。誰か知っていますか？）これを行う方法を知っていますが、それが最良の方法。FileStreamSeekSeekBeginReadEndRead

2. 構造とkernel32.dllSystem.Threading.Overlappedの関数へのP\Invokeを 中心とした別の方法があるようです。ReadFileEx

   残念ながら、特に管理された言語では、サンプルが不足しています。このルート（動作させることができる場合）にはThreadPool.BindHandle、スレッドプール内のメソッドとIO完了スレッドも含まれているようです。これがウィンドウの下でこのシナリオを処理するための認可された方法であるという印象を受けますが、私はそれを理解しておらず、初心者に役立つドキュメントへのエントリポイントを見つけることができません。

3. 他に何かありますか？

4. コメントの中で、jacobはFileStream、飛行中の読み取りごとに新しいものを作成することを提案しています。

5. ファイル全体をメモリに読み込みます。

   これは、データベースが小さい場合に機能します。コードベースは小さく、他にも多くの非効率性がありますが、データベース自体はそうではありません。また、大規模なデータベース（ページング、外部ソーティングなど、複雑さの大部分を占めることが判明）を処理するために必要なすべての簿記を確実に実行していることを確認したいと思います。誤ってごまかしやすい。

編集

解決策1に疑問がある理由の明確化：BeginReadからEndReadまでずっと単一のロックを保持するということは、別の読み取りが進行中であるという理由だけで読み取りを開始したい人をブロックする必要があることを意味します。新しい読み取りを開始するスレッドは、結果が利用可能になる前に（一般に）さらにいくつかの作業を実行できる可能性があるため、これは間違っていると感じます。（実際、これを書くだけで、新しい解決策を考えるようになりました。私は新しい答えとして置きました。）

Win32 プロダクション プロセスでのデッドロックによる明らかなハングをデバッグするための手順とテクニックは何ですか。この目的で WinDbg を使用できると聞きましたが、これを実現する方法について明確なヒントを教えてください。