Wie wird Win32 ereignisgesteuerte Programmierung unter der Haube umgesetzt?

Question

In einer Win32 C ++ Anwendung, starten wir eine Nachrichtenschleife, die Nachrichten aus einer Warteschlange abruft, übersetzt sie und dann versendet sie. Schließlich jede Nachricht erreicht unsere WndProc, wo das zugehörige Ereignis gehandhabt werden kann.

Ich verstehe, dass ein Teil. Was ich nicht verstehe ist, das zwischen Treiben. Im Einzelnen:

1. Verschiedene Arten von OS Interrupt-Handler muss in der genannten ‚Message Queue‘, platzieren Nachrichten sein, aber wo innerhalb des Prozessadressraumes wohnt, diese Warteschlange? Wie ist es mit dem Interrupt-Handler-Code ausgesetzt?
2. Was bedeutet es, zu ‚übersetzen‘ die Botschaft? Was den Anruf tut wirklich tun, um TranslateMessage()?
3. Sobald von DispatchMessage() versandt, was alle Orte der Nachricht schwingen durch nicht vor meinem WndProc erreicht (das heißt, was ist das OS mit ihm tun)?

Wenn jemand die Antworten auf die oben weiß, freundlich meine Neugier befriedigen. Danke.

Answer 1

Das Betriebssystem unterhält eine Nachrichtenwarteschlange, wo es um die Ereignisse legt (zum Beispiel von Unterbrechungen oder anderen Quellen). Er sendet dann die Nachrichten aus der Warteschlange an allen Fenstern, in Abhängigkeit von der Nachricht (zum Beispiel wird es nicht Schlüsselbotschaften an ein Fenster senden, die den Fokus nicht besitzt).

Applikationen können ihre eigene Warteschlange haben Nachrichten zu verarbeiten. Diese Warteschlangen werden erstellt auf Anfrage (nur bei Bedarf ).

Übersetzen eine Nachricht verwendet wird, um Nachrichten zu erstellen, die nicht ‚echte‘ Ereignisse sind. Zum Beispiel wird die WM_CONTEXTMENU Nachricht ‚übersetzt‘ entweder von einem rechten Mausklick oder die Kontextmenü-Taste oder Shift-F10. Die WM_CHAR von WM_KEYDOWN Nachrichten übersetzt. Und natürlich viele andere Nachrichten werden ‚übersetzt‘ auf diese Weise.

Eine Nachricht wird an jedes Fenster geschrieben, die sie erhalten sollen. Das Betriebssystem entscheidet, abhängig von der Art der Meldung, ob ein Fenster der Nachricht erhalten soll oder nicht. Die meisten Nachrichten werden vom System gewartet, das heißt, wird die Nachricht nicht an ein anderes Fenster gepostet, bis er durch das Fenster verarbeitet wurde. Dies hat einen großen Einfluss für Broadcast-Nachrichten: wenn ein Fenster nicht zurück, wenn diese Nachrichtenverarbeitung, die Warteschlange

Answer 2

Es hängt davon ab, wie Sie Ihre Nachricht gesendet wird und wie es behandelt werden.

Wenn Sie Sendmessage aufrufen, wenn das Zielfenster durch den aktuellen Thread gehört, umgeht der Anruf die Nachrichtenwarteschlange für das Fenster und der Fenstermanager die WindowProc auf das Zielfenster direkt aufruft. Wenn das Zielfenster von einem anderen Thread gehört, effektiv der Window-Manager ruft Postmessage und Pumpen Fenstermeldungen, bis das Zielfenster kehrt aus dem Fenster proc.

Wenn Sie anrufen Postmessage, die Window-Manager Marschälle die Nachrichtenparameter und fügt das entsprechende Objekt auf der Nachrichten-Warteschlange für das Zielfenster. Wenn es GetMessage nächstes ruft die Nachricht aus der Nachrichtenwarteschlange entfernt wird.

Der Fenstermanager registriert auch für rohe Eingabeereignisse von den Eingabegeräten (Tastatur und / oder Maus) und erzeugt Nachrichten für diese Eingabeereignisse. Er fügt dann diese Nachrichten in der Warteschlange als angemessen (die Verarbeitung von Eingabeereignissen sind kompliziert, weil es hängt davon ab, welche Nachrichten sind bereits in der Nachrichten-Warteschlange für das Fenster).

Wie Stefan angegeben ist, übersetzt nur Translatezugriffstasten -. Zum Beispiel das Tastenfolgen konvertiert Nachrichten in WM_COMMAND

  

Verschiedene Arten von OS Interrupt-Handler muss in der genannten ‚Message Queue‘, platzieren Nachrichten sein, aber wo innerhalb des Prozessadressraumes wohnt, diese Warteschlange? Wie ist es mit dem Interrupt-Handler-Code ausgesetzt?

Windows ist mit Gewinden verbunden. Jeder Thread mit einem Fenster hat ein Gewinde Warteschlange in dem Adressraum des Prozesses. Das Betriebssystem verfügt über eine interne Warteschlange in seinem eigenen Adressraum für die Hardware-generierte Ereignisse. Verwendung Details des Ereignisses und andere Zustandsinformationen (beispielsweise das Fenster den Fokus hat), übersetzt das Betriebssystem der Hardware-Ereignisse in Nachrichten, die dann in der entsprechenden Thread-Warteschlange gestellt.

Nachrichten, die direkt in dem Gewinde Warteschlange für das Zielfenster platziert gebucht werden.

Nachrichten, die in der Regel direkt verarbeitet gesendet werden, werden (unter Umgehung der Warteschlange).

Die Details erhalten behaart. Zum Beispiel sind die Gewinde Warteschlangen mehr als Listen von Meldungen - sie auch einige Statusinformationen erhalten. Einige Nachrichten (wie WM_PAINT) sind nicht wirklich die Warteschlange gestellt, aber von den zusätzlichen Statusinformationen synthetisieren, wenn Sie die Warteschlange abfragen, und es ist leer. Nachrichten, die an Fenstern von anderen Threads im Besitz gesendet werden, tatsächlich zu der Empfängerwarteschlange geschrieben und nicht direkt verarbeitet werden, aber das System macht es wie eine normale Blockierung von dem Anrufer Sicht senden erscheinen. Hilarity ergibt sich, wenn dieses Deadlock führen kann (wegen der Rundschreiben an die ursprüngliche Thread sendet).

Die Jeffrey Richter Bücher haben viele (alle?) Der blutigen Details. Meine Ausgabe ist alt (Advanced Windows). Die aktuelle Ausgabe erscheint Windows über C / C ++ aufgerufen werden.

Das Betriebssystem eine Menge Arbeit ist, um den Nachrichtenstrom rational erscheinen zu lassen (und relativ einfach) an den Anrufer.

  

Was bedeutet es, zu ‚übersetzen‘ die Botschaft? Was den Anruf an Translate tut () wirklich tun?

Es sieht für virtuelle Schlüsselbotschaften, und wenn er einen Schlüssel-down / key-up Kombination erkennt, es Zeichen-Nachrichten erstellt. Wenn Sie nicht nennen Translate , werden Sie nicht Zeichen-Nachrichten wie WM_CHAR erhalten.

Ich vermute, dass es die Zeichennachricht (im Gegensatz, sich zu veröffentlichen) direkt vor der Rückkehr sendet. Ich habe noch nie überprüft, aber ich glaube, daran zu erinnern, dass die WM_CHAR-Nachrichten ankommen kurz vor dem WM_KEYUP.

  

Sobald von Dispatch versandt (), was allen Orten hat die Nachricht Swing von vor meinem WndProc erreichen (das heißt, was ist das OS mit ihm tun)?

Dispatch leitet die Nachricht an die WndProc für das Zielfenster. Auf dem Weg dorthin, es einige Haken eine Chance bekommen kann die Nachricht (und möglicherweise stören sie) zu sehen.

Um die letzte Teilfrage zu adressieren, eine geschickte Nachricht an Ihre WindowProc gehen, nachdem sie durch alle Haken geleitet worden sind (WH_CALLWNDPROC)

Nicht absolut positiv über diese aber meine beste Vermutung sagt:

1. Die Warteschlange ist ein Systemobjekt, das Sie mit Win32-API-Aufrufen zugreifen. Es ist nicht in dem Adressraum Prozess überhaupt. So sind die Interrupt-Handler darauf zugreifen können (wahrscheinlich durch die HAL (Hardware Abstraction Layer) des Kernels).

2. In Win16, nahm dieser Aufruf die verschiedenen Unterpunkte einer größeren Nachricht und sie zu einem Ganzen püriert. So würde die Translate WM_KEYPRESS hinzufügen, wenn sie die entsprechenden WM_KEYDOWN WM_KEYUP Sequenz gefunden. Es wäre auch verschiedene Tastenklick Nachrichten in Doppelklick Nachrichten basierend auf internen Einstellung und die Zeitstempel der Nachrichten drehen. Ob es noch tut dies in Win32, ich weiß es nicht.

3. Dispatch ist wahrscheinlich, wo Fenster Nachricht Haken verarbeitet bekommen. Also, wenn es ist ein Haken an Ihrem Fenster, entweder hier genannt, oder wenn die GetMessage genannt wird. Ich bin mir nicht sicher. Other than that, Dispatch sieht nur die WndProc-Adresse eines mit dem Fenster verbunden ist und nennt es. Es gibt nicht viel anderes zu tun.

Ich hoffe, das hilft.

Answer 3

Es hängt davon ab, wie Sie Ihre Nachricht gesendet wird und wie es behandelt werden.

Wenn Sie Sendmessage aufrufen, wenn das Zielfenster durch den aktuellen Thread gehört, umgeht der Anruf die Nachrichtenwarteschlange für das Fenster und der Fenstermanager die WindowProc auf das Zielfenster direkt aufruft. Wenn das Zielfenster von einem anderen Thread gehört, effektiv der Window-Manager ruft Postmessage und Pumpen Fenstermeldungen, bis das Zielfenster kehrt aus dem Fenster proc.

Wenn Sie anrufen Postmessage, die Window-Manager Marschälle die Nachrichtenparameter und fügt das entsprechende Objekt auf der Nachrichten-Warteschlange für das Zielfenster. Wenn es GetMessage nächstes ruft die Nachricht aus der Nachrichtenwarteschlange entfernt wird.

Der Fenstermanager registriert auch für rohe Eingabeereignisse von den Eingabegeräten (Tastatur und / oder Maus) und erzeugt Nachrichten für diese Eingabeereignisse. Er fügt dann diese Nachrichten in der Warteschlange als angemessen (die Verarbeitung von Eingabeereignissen sind kompliziert, weil es hängt davon ab, welche Nachrichten sind bereits in der Nachrichten-Warteschlange für das Fenster).

Wie Stefan angegeben ist, übersetzt nur Translatezugriffstasten -. Zum Beispiel das Tastenfolgen konvertiert Nachrichten in WM_COMMAND

Answer 4

  

Verschiedene Arten von OS Interrupt-Handler muss in der genannten ‚Message Queue‘, platzieren Nachrichten sein, aber wo innerhalb des Prozessadressraumes wohnt, diese Warteschlange? Wie ist es mit dem Interrupt-Handler-Code ausgesetzt?

Windows ist mit Gewinden verbunden. Jeder Thread mit einem Fenster hat ein Gewinde Warteschlange in dem Adressraum des Prozesses. Das Betriebssystem verfügt über eine interne Warteschlange in seinem eigenen Adressraum für die Hardware-generierte Ereignisse. Verwendung Details des Ereignisses und andere Zustandsinformationen (beispielsweise das Fenster den Fokus hat), übersetzt das Betriebssystem der Hardware-Ereignisse in Nachrichten, die dann in der entsprechenden Thread-Warteschlange gestellt.

Nachrichten, die direkt in dem Gewinde Warteschlange für das Zielfenster platziert gebucht werden.

Nachrichten, die in der Regel direkt verarbeitet gesendet werden, werden (unter Umgehung der Warteschlange).

Die Details erhalten behaart. Zum Beispiel sind die Gewinde Warteschlangen mehr als Listen von Meldungen - sie auch einige Statusinformationen erhalten. Einige Nachrichten (wie WM_PAINT) sind nicht wirklich die Warteschlange gestellt, aber von den zusätzlichen Statusinformationen synthetisieren, wenn Sie die Warteschlange abfragen, und es ist leer. Nachrichten, die an Fenstern von anderen Threads im Besitz gesendet werden, tatsächlich zu der Empfängerwarteschlange geschrieben und nicht direkt verarbeitet werden, aber das System macht es wie eine normale Blockierung von dem Anrufer Sicht senden erscheinen. Hilarity ergibt sich, wenn dieses Deadlock führen kann (wegen der Rundschreiben an die ursprüngliche Thread sendet).

Die Jeffrey Richter Bücher haben viele (alle?) Der blutigen Details. Meine Ausgabe ist alt (Advanced Windows). Die aktuelle Ausgabe erscheint Windows über C / C ++ aufgerufen werden.

Das Betriebssystem eine Menge Arbeit ist, um den Nachrichtenstrom rational erscheinen zu lassen (und relativ einfach) an den Anrufer.

  

Was bedeutet es, zu ‚übersetzen‘ die Botschaft? Was den Anruf an Translate tut () wirklich tun?

Es sieht für virtuelle Schlüsselbotschaften, und wenn er einen Schlüssel-down / key-up Kombination erkennt, es Zeichen-Nachrichten erstellt. Wenn Sie nicht nennen Translate , werden Sie nicht Zeichen-Nachrichten wie WM_CHAR erhalten.

Ich vermute, dass es die Zeichennachricht (im Gegensatz, sich zu veröffentlichen) direkt vor der Rückkehr sendet. Ich habe noch nie überprüft, aber ich glaube, daran zu erinnern, dass die WM_CHAR-Nachrichten ankommen kurz vor dem WM_KEYUP.

  

Sobald von Dispatch versandt (), was allen Orten hat die Nachricht Swing von vor meinem WndProc erreichen (das heißt, was ist das OS mit ihm tun)?

Dispatch leitet die Nachricht an die WndProc für das Zielfenster. Auf dem Weg dorthin, es einige Haken eine Chance bekommen kann die Nachricht (und möglicherweise stören sie) zu sehen.

Answer 5

Um die letzte Teilfrage zu adressieren, eine geschickte Nachricht an Ihre WindowProc gehen, nachdem sie durch alle Haken geleitet worden sind (WH_CALLWNDPROC)

Answer 6

Nicht absolut positiv über diese aber meine beste Vermutung sagt:

1. Die Warteschlange ist ein Systemobjekt, das Sie mit Win32-API-Aufrufen zugreifen. Es ist nicht in dem Adressraum Prozess überhaupt. So sind die Interrupt-Handler darauf zugreifen können (wahrscheinlich durch die HAL (Hardware Abstraction Layer) des Kernels).

2. In Win16, nahm dieser Aufruf die verschiedenen Unterpunkte einer größeren Nachricht und sie zu einem Ganzen püriert. So würde die Translate WM_KEYPRESS hinzufügen, wenn sie die entsprechenden WM_KEYDOWN WM_KEYUP Sequenz gefunden. Es wäre auch verschiedene Tastenklick Nachrichten in Doppelklick Nachrichten basierend auf internen Einstellung und die Zeitstempel der Nachrichten drehen. Ob es noch tut dies in Win32, ich weiß es nicht.

3. Dispatch ist wahrscheinlich, wo Fenster Nachricht Haken verarbeitet bekommen. Also, wenn es ist ein Haken an Ihrem Fenster, entweder hier genannt, oder wenn die GetMessage genannt wird. Ich bin mir nicht sicher. Other than that, Dispatch sieht nur die WndProc-Adresse eines mit dem Fenster verbunden ist und nennt es. Es gibt nicht viel anderes zu tun.

Ich hoffe, das hilft.