Was ist ein Handle?

[AHT]

Eine ganz dumme, aber sehr interessante Frage... Was ist eigentlich ein Handle . (Bin gespannt, was dabei rumm kommt ).

[Frabbing]

Ein Handle ist ein Zeiger auf eine oder ein Schlüssel zu einer Datenstruktur, auf die ein Satz von Funktionen zugreift.

[RGH]

Ein Handle ist so etwas wie ein Griff; im Softwarebereich also ein Wert, der einem den Zugriff auf bestimmte Daten ermöglicht. Ein Handle auf eine Bitmap ist also jener Wert, der mir den Zugriff auf die Eigenschaften und Daten dieser Bitmap ermöglicht. Das Ergebnis der Create-Funktionen in XProfan ist in der Regel ein solches Handle. Funktionen, die auf das erzeugte Objekt, sei es nun ein Bild, Icon, Dialogelement, eine Liste, ein String-Grid oder was auch immer. zugreifen und etwas damit anfangen, benötigen dieses eindeutige Handle.

Erzeuge ich zum Beispiel mehrere Editfelder in einem Dialog, hat jedes ein eigenes eindeutiges Handle. Der Funktion Gettext$() übergebe ich nun das Handle des Editfeldes, dessen Inhalt ich ermitteln will.

(Systemtechnisch gesehen verbergen sich hinter dem Wert des Handles oftmals Speicheradressen, an denen die Informationen über das Objekt liegen. Das muss allerdings nicht zwingend so sein. Es wären auch Handles denkbar, die eine Ordnungszahl o.ä. darstellen.)

Gruß
Roland

[Corone]

hier noch ein Überblick

Handle ? Wikipedia

[AHT]

Zitat von Frabbing

Ein Handle ist ein Zeiger auf eine oder ein Schlüssel zu einer Datenstruktur, auf die ein Satz von Funktionen zugreift.

Stimmt so nicht ganz. Schau dir mal den Wert eines Fensterhandles oder den Wert eines Prozesshandles an - kann das ein Pointer sein? Gerade bei den Handles von Fenstern fällt da unter NT basierenden Systemen etwas ganz bestimmtes auf, das hier sehr wichtig ist.

@Roland und @Carone: Zu ungenau, damit kann man in der Praxis nichts anfangen.

[sekoenig]

Also ich finde hier wurde einiges gesagt, was sehr richtig ist. Und meiner Meinung nach waren einige Beschreibungen nicht zu ungenau, sondern umgekehrt eher zu spezifisch.

Denn in der Praxis ist es meiner Ansicht nach gerade nicht wichtig, was letztlich hinter der Zahl, die man "Handle" nennt, steckt, sondern nur, dass man darüber ein bestimmtes "Objekt" (Beispiele wurden ja schon genannt) gegenüber einer Schnittstelle (Satz von Funktionen) eindeutig identifizieren kann.

MfG

Sebastian

[RGH]

Zitat von AHT

Stimmt so nicht ganz. Schau dir mal den Wert eines Fensterhandles oder den Wert eines Prozesshandles an - kann das ein Pointer sein? Gerade bei den Handles von Fenstern fällt da unter NT basierenden Systemen etwas ganz bestimmtes auf, das hier sehr wichtig ist.

Und was, bitte sehr? Wenn Du es schon weißt, dann frage doch nicht danach, sondern teile Dein Wissen der Welt mit! (Oder bist Du ein Lehrer? Die fragen auch immer nach Dingen, die sie schon wissen ... )

In der Praxis reicht es mir, zu wissen, auf was ich mit dem Handle zugreifen. Wenn ich das Handle eines Editfeldes habe, dann kann ich in das Editfeld schreiben, es auslesen, sein Aussehen ändern und manches mehr. Dem Anwendungsprogrammierer ist es in der Regel völlig egal, was sich nun genau hinter dem Wert verbirgt, ob er nun eine Adresse, Listennummer oder sonst etwas ist.

Gruß
Roland

[Frabbing]

Zitat:
Zitat von Frabbing
Ein Handle ist ein Zeiger auf eine oder ein Schlüssel zu einer Datenstruktur, auf die ein Satz von Funktionen zugreift.

Stimmt so nicht ganz. Schau dir mal den Wert eines Fensterhandles oder den Wert eines Prozesshandles an - kann das ein Pointer sein?

Ein Pointer oder ein Schlüssel...

[AHT]

Zitat von RGH

Und was, bitte sehr?

Ich will es etwas genauer haben, warum kommt später.
Nimms mir nicht übel, aber es gibt da eine alte "Bauernregel":

Wenn der Hahn kräht auf dem Mist, ändert sich das Wetter, oder es bleibt wie es ist.

Nimm mal deine Aussage und versuche darauf basierend ein Programm zu schreiben, dass von anderen Prozessen geöffnete Hooks schließt.
Fazit: Man kann mit solchen Aussagen nicht arbeiten - und hier soll am Ende etwas stehen, mit dem man arbeiten kann. Es soll also ans "eingemachte" gehen und nicht an das vergammelte Kompott vom letzten Mittag.

Wenn Du es schon weißt, dann frage doch nicht danach, sondern teile Dein Wissen der Welt mit! (Oder bist Du ein Lehrer? Die fragen auch immer nach Dingen, die sie schon wissen ... )

Ich kenne die Antwort nicht komplett, sondern möchte, dass sich auch andere etwas Gedanken darüber machen - sonst nützt mir hier das Posten nichts und ich kann mein Wissen besser für mich behalten und selbst etwas damit anfangen.

Denn in der Praxis ist es meiner Ansicht nach gerade nicht wichtig, was letztlich hinter der Zahl, die man "Handle" nennt, steckt, sondern nur, dass man darüber ein bestimmtes "Objekt" (Beispiele wurden ja schon genannt) gegenüber einer Schnittstelle (Satz von Funktionen) eindeutig identifizieren kann.

Solange man sich im eigenen Prozess befindet, hast du damit recht - ansonsten nicht.

Wie gesagt, das spiegelt meinen Wissenstand wieder - der ist nicht vollständig und an manchen Ecken wohl auch nicht korrekt.
Ich fange noch einmal mit Franks Antwort an, die finde ich schon recht gut:

Ein Handle ist ein Zeiger auf eine oder ein Schlüssel zu einer Datenstruktur, auf die ein Satz von Funktionen zugreift.

Das worauf es mir ankommt, habe ich im Zitat markiert.
Die Datenstruktur nennen wir mal hier Objekt (oder Object), die nennt Microsoft auch so, und dann wird es einfacher.

Die API GetGuiResources bietet hier für den Anfang scheinbar etwas Hilfe. Über dies API kann man die Anzahl bestimmter Objekte ermitteln, die ein Prozess erzeugt hat. Der zweite Parameter gibt an, für welche Art von Objekt die Anzahl ermittelt werden soll - halt stopp - es gibt unterschiedliche Arten von Objekten?? Wenn es unterschiedliche Arten von Objekten gibt, gibt es vielleicht auch unterschiedliche Arten von Handles! Und genau das ist der Fall.

Was ein Handle genau im Einzellfall ist, ist also abhängig von dem Objekt, auf das ein Handle verweist. Es gibt Userhandles (Fensterobjekte), GDI Handles (Handles auf Objekte zum Zeichnen), Kernelhandles (Handles auf Objekte, die in der Regel durch APIs der Kernel32.dll erzeugt werden) und Handles auf Speicherbereiche - mehr sind mir im Augenblick nicht bekannt.

DEsweiteren ist das, was ein Handle ist, abhängig davon, wie das jeweilige Betriebsystem diese Objekte verwaltet. Microsoft hat zwei Arten von Betriebsystemen herausgebracht
a) Windows 95/98/ME
b) NT basierende Betriebsysteme
Was ein Handle ist, ist bei a) und b) nicht gleich - da ich von a) diesbezüglich keine Ahnung habe und die Technik veraltet ist, kann ich hier allerhöchsten Auskunft über b) geben . Wer für a) näheres weiß, kann sich gerne hier einbringen.

[Frabbing]

Es gibt Userhandles (Fensterobjekte), GDI Handles (Handles auf Objekte zum Zeichnen), Kernelhandles (Handles auf Objekte, die in der Regel durch APIs der Kernel32.dll erzeugt werden) und Handles auf Speicherbereiche - mehr sind mir im Augenblick nicht bekannt.

Ja, aber ist dabei nicht egal, ab der Handle ein Zeiger auf einen Speicher ist, oder nur ein Schlüssel ist, um den passenden Zeiger aus einer Liste heraus zu finden, der wiederum nur ein Zeiger auf einen Speicher ist, oder vielleicht ein weiterer Schlüssel?

Ich denke, wenn ich "nur" API benutze, benötige ich dieses Wissen doch im Grunde gar nicht. Sollten in einer neuen Windowsversion Änderungen am Handle vorgenommen worden sein, so werden die ja innerhalb der API wieder ausgeglichen sein, um kompatibel zu bleiben. Für den Programmierer ändert sich dadurch (in der Regel) aber nichts.

Anders ist es, wenn man nach deiner Methode vorgeht und bei den wesentlich Sachen gar nicht mit der API arbeitet, sondern sich mehr manuell durch den Handle-und Speicher-Dschungel hangelt, um seine Informationen zu erhalten. Diese Methode ist sicherlich sehr effektiv (Hut ab vor soviel Try&Error), da auch Beschränkungen durchbrochen werden können, die vom Betriebssystem (warum auch immer) auferlegt wurden.
Gab es jedoch bei einem neuen Betriebssystem dort Änderungen, bist du gezwungen, in deinen Programmen Anpassungen vorzunehmen. Daher müsste wohl bei verschiedenen Systemen auch verschieden verfahren werden, und deine Programme an jedes neue System angepasst werden. Dieses Problem haben die Nur-API-Benutzer sicher seltener...

Ich hoffe, ich hab das so mal überblickend zusammen gefasst.

[AHT]

Zitat von Frabbing

Ich denke, wenn ich "nur" API benutze, benötige ich dieses Wissen doch im Grunde gar nicht.

Das ist ein Irrtum, denn nur mit der API lassen sich da einige Sachen Zaubern, die man gar nicht für möglich hält - und das nur mit dem Wissen, was ein Handle ist.
Es ist so richtiger: Wenn ich nichts spezielles programmieren will, benötige ich dieses Wissen nicht. Manch einer kommt ja auch mit dem zurecht, was XProfan von sich aus bietet - der braucht, um glücklich zu werden, auch keine API .

Zitat von Frabbing

Anders ist es, wenn man nach deiner Methode vorgeht und bei den wesentlich Sachen gar nicht mit der API arbeitet, sondern sich mehr manuell durch den Handle-und Speicher-Dschungel hangelt, um seine Informationen zu erhalten.

Darum geht es mir hier nicht. Der "Dschungel", durch den man sich da wühlen müsste, befindet sich in der Regel im Kernel - und auf den haben normale Programme gar keinen Zugriff. Was du hier wohl im Auge hast, habe ich praktisch in PW-Show umgesetzt, um Vista auszutricksen. Das befindet sich aber auf einem ganz anderen Level - hat damals, als ich mich im XProfan Forum damit beschäftigt habe, ja sowieso nur Sebastian verstanden, was der Umstand im Prinzip sollte .

Zitat von Frabbing

Diese Methode ist sicherlich sehr effektiv (Hut ab vor soviel Try&Error), da auch Beschränkungen durchbrochen werden können, die vom Betriebssystem (warum auch immer) auferlegt wurden.

Die "Zauberei" beschränkt sich bei mir vor allem auf "Zauberei" mittels API, der Try&Error geht gegen 0, da alles Neue auf dem selben Betriebsystem basiert.

Zitat von Frabbing

Daher müsste wohl bei verschiedenen Systemen auch verschieden verfahren werden, und deine Programme an jedes neue System angepasst werden.

Das siehst du falsch. Microsoft hat zwei Arten von Betriebsystemen entwickelt: a) und b) -> siehe oben. Es geht hier um grundlegende Sachen von b). Solange Microsoft kein Betriebsystem c) entwickelt, wird sich da wohl nichts ändern. Bis Vista hat sich da jedenfalls nichts geändert.

Zitat von Frabbing

Dieses Problem haben die Nur-API-Benutzer sicher seltener...

Irrtum, die schlagen sich auch mit a) und b) herum.

Es geht mir um das, was du anfänglich als "Schlüssel" bezeichnet hast und jetzt korrekter als "Liste" darstellst.
Um das mal weiterzuführen: Einige Objekthandles sind also direkte (oder indirekte?) Pointer auf einen (auslesbaren?) Speicherbereich, andere wiederum sind Einträge in einer Liste - oft der Index dieses Eintrages.
Es geht mir darum, welche Objekthandles in welcher Liste zu finden sind und welche Objekthandles einfach nur Pointer sind.
Welche Objekte gehören also, neben den Fenstern, zu den Userobjekten? Hat sich mal jemand damit befasst?

[Frabbing]

Es geht mir darum, welche Objekthandles in welcher Liste zu finden sind und welche Objekthandles einfach nur Pointer sind.
Welche Objekte gehören also, neben den Fenstern, zu den Userobjekten? Hat sich mal jemand damit befasst?

Ich bislang nicht. Informationen über solche Listen wären aber sicher nie verkehrt.

[AHT]

Zitat von Frabbing

Ich bislang nicht. Informationen über solche Listen wären aber sicher nie verkehrt.

Wie gesagt, hängt davon ab, was man tun möchte und ob man bereit ist, sich manche APIs auch mal "verkehrtherum" anzusehen.
Soweit ich die habe, werden die Infos kommen - anhand einiger Beispielprogramme, damit man selbst nachsehen und mitdenken kann.
Die Infos, von denen ich hier Rede, habe ich nirgendwo gelesen sondern basieren auf dem, was ich bei der Arbeit mit Windows selbst sehe - die sind also nicht komplett.
Es gibt hier ja genug Leute, die viel mehr können, als nur Code von einer Ecke auf die andere zu kopieren. Vielleicht denkt ja manch einer von denen hier mit, bringt eigene Gedanken ein oder komplettiert hier oder da etwas - wäre schön.

[p. specht]

Hochinteressant... Mir fehlen nur leider sämtliche Voraussetzungen, Konzepte, Tools, Sprachregelungen, Übersichten, Konventionen, Algorithmenkenntnisse, programmatisch-philosophischen Konzepte, Durchblick und (vor allem) die Zeit dazu, das alles zu erforschen. Und ich fürchte, da bin ich beim einen oder anderen Punkt nicht allein.

Der Witz daran ist: Ich war (in anderen Programmierdingen) früher ganz ähnlich, und konnte nicht verstehen, daß andere mir nicht mal ansatzweise folgen konnten. Allerdings hat sich dann herausgestellt, daß das auch ein Hindernis war, ein normales, bürgerliches Leben zu führen, sich anstädig um seine Alte zu kümmern und 16 Kinder in die Welt zu setzen. M.a.W.: Es ist eine Frage der Prioritäten.

Nichts-desto-Trotz: Aus meiner Sicht bitte unbedingt weitermachen, solange das so tolle Resultate bringt! Man fühlt sich auch irgendwie gut, wenn da von den "M$-Programmiergöttern" gezeigt wird, daß sie auch nur mit Wasser kochen...

Herzliche Grüße aus Wien
P. Specht

[AHT]

Zitat von p. specht

Hochinteressant... Mir fehlen nur leider sämtliche Voraussetzungen, Konzepte, Tools, Sprachregelungen, Übersichten, Konventionen, Algorithmenkenntnisse, programmatisch-philosophischen Konzepte, Durchblick und (vor allem) die Zeit dazu, das alles zu erforschen. Und ich fürchte, da bin ich beim einen oder anderen Punkt nicht allein.

Ist alles nicht so wichtig, das fehlt mir auch alles.

Zitat von p. specht

Der Witz daran ist: Ich war (in anderen Programmierdingen) früher ganz ähnlich, und konnte nicht verstehen, daß andere mir nicht mal ansatzweise folgen konnten. Allerdings hat sich dann herausgestellt, daß das auch ein Hindernis war, ein normales, bürgerliches Leben zu führen, sich anstädig um seine Alte zu kümmern und 16 Kinder in die Welt zu setzen. M.a.W.: Es ist eine Frage der Prioritäten.

Ich habe erst drei Kinder , fehlen also noch 13, um die ich mich heute abend erst mal vorrangig kümmern muss - ist also schon mal der richtige Denkansatz.