bedeutung des handles..

Hammer

Eine Anmerkung aus einem tutorial:

"(hInstance)Diesem Handle sind daten, die windows intern über das unser
Programm gespeichert hat(z.B., wo sich unsere EXE befindet)"

Und hier eine Anmerkung zu dem ersten obigen beispiel mit der import-tabelle:

"Haben wir die user32.dll gefunden, liegt in pImage->FirstThunk die relative Adresse (RVA) eines Feldes von IMAGE_THUNK_DATA Strukturen. In einer von denen ist das was wir suchen, nämlich der Verweis auf die echte Adresse von MessageBoxA, den wir überschreiben wollen. Da es sich wie gesagt um eine relative Adresse handelt, addieren wir noch die Basisadresse des Moduls, also hModEXE dazu. Damit haben wir eine Absolute Adresse und können unsere Funktion suchen"

hModExe wird als Basisadresse des Moduls bezeichnet...

ich denke das sagt alles..

mfg

PAD

Wo steht dieses Tutorial.

Die Aussage von MFK und dem Tutorial wiedesprechen sich nicht. Das Handle ist ein Element dessen eigener Inhalt
uns nicht zu interessieren hat. Mithilfe des Handles kann ich an die entsprechenden Adressen herankommen.
Das Handle ist nicht die Adresse.

-King-

PAD schrieb:

Das Handle ist nicht die Adresse.

Das Handle ist die Adresse. Deswegen funktioniert beispielweise auch sowas hier:

HINSTANCE GetMyHinstance(VOID)
{
   MEMORY_BASIC_INFORMATION mbi;

   VirtualQuery((PVOID)GetMyHinstance, &mbi, sizeof(mbi));
   return((HINSTANCE)mbi.AllocationBase);
}

Das gilt aber nur bei HINSTANCE. Bei anderen Handles kann das anders sein.

Hammer

hmm, so wies aussieht gibts entweder unstimmigkeiten oder es ist wirklich so, dass die handles unter sich unterschiedliche bedeutungen haben.

aber welchen sinn sollte es sonst haben den wert eines handles irgendwo draufzuaddieren, wenn es keine adresse ist.

z.b. beim suchen der user32.dll in der importtabelle:

hModExe = GetModuleHandle(NULL);

for (;pImage->Name; pImage++)
    {
		char *pModName = (char*)((char*)hModExe + pImage->Name);
        if (!lstrcmpiA(pModName, "user32.dll")) 
		{ ...

-King-

Hammer schrieb:

hmm, so wies aussieht gibts entweder unstimmigkeiten oder es ist wirklich so, dass die handles unter sich unterschiedliche bedeutungen haben.

Was für Unstimmigkeiten? Und was meinst Du mit 'Handles unter sich'? HINSTANCE ist HINSTANCE, und zurzeit ist das eine Adresse. Du kannst Dich nur nicht darauf verlassen, daß das auch in Zukunft so sein wird.

Hammer

mit handles unter sich meinte ich, dass ein handle von einem Registry-Schlüssel eine andere Bedeutung haben könnte, wie der handle einer bitmap oder eines moduls...
oder repräsentieren handles grundsätzlich adressen, sodass ev. der handle einer bitmap z.b. einen pointer auf das erste byte der bitmap darstellt ?

oder repräsentieren handles grundsätzlich adressen, sodass ev. der handle einer bitmap z.b. einen pointer auf das erste byte der bitmap darstellt ?

nein

-King-

Nein hat natürlich recht. Aber vielleicht hättest Du's gern noch etwas ausführlicher.

Hammer schrieb:

, dass ein handle von einem Registry-Schlüssel eine andere Bedeutung haben könnte,

Das ist ein Kernel-Objekt. Das Handle ist ein Index in die Handle-Table des Prozesses und keine Adresse.

wie der handle einer bitmap oder eines moduls...

Das mit dem Modul ist ja bereits geklärt. Das Bitmap aber ist ein GDI-Objekt. Ein GDI-Handle ist auch nur ein Index in eine Tabelle (LOWORD). Zusätzlich findest Du im HIWORD Informationen über das Objekt (Pen, Brush, StockObject, usw.). Diese Tabelle liegt, im Gegensatz zu den Kernel-Objekten, im User-Mode. Aber auch hier: Keine Adresse.

peterchen

@Hammer:
Der klassische Unterschied zwischen Vertrag (was du darfst), Deklaration (was der Compiler dich läßt), und Implementation (was heut mal auf deinem rechner geht). Ein kleines Beispiel:

char * minstr(char * a, char * b)
{
  if (strcmp(a,b) <= 0)
    return a;
  else
    return b;
};

Vertrag: minstr gibt einen Zeiger auf den kleineren String von a und b (beides nicht-NULL zeiger auf Null-Terminierte Strings)
Deklaration: minstr empfängt zwei Zeiger auf char und gibt einen Zeiger auf char zurück
Implementation: Vielleicht kann man es ja ausnutzen, daß dort nicht "<" sondern "<=" steht - aber das funktioniert nur solange, bis jemand der Meinung ist daß "<" den Vertrag auch erfüllt und das stillschweigend ändert. Oft werden solche Angaben im Vertrag "vergessen", oder sind im günstigsten Fall als "implementaitonsspezifisch" markiert.

Warum der lange Bogen:
Die Frage ist nicht, ob HINSTANCE + Modulnamenlänge nun auf die Reloc-Tabelle zeigt oder nicht. Sondern: Was willst du mit der Reloc-Tabelle anfangen? Gibt es einen "legalen" Weg, das zu erreichen was auch immer du vorhast? Wie kannst du solche Implementationsabhängigkeiten isolieren?

Microsoft sichert dir halt nur zu, das HINSTANCE halt ein Handle ist, über den du sonst nichts weißt.

WinYP kann z.B. spezielle HINSTANCE's einführen, die sich nicht an die Basisadressensache halten. Oder MS liefert ein "Win32 Sandbox Update" aus, die ein schreckliches Sicherheitsloch stopft und nebenbei noch alle HINSTANCE's durch eine Hash-Tabelle schiebt. Bumm.

PAD

@peterchen. Gut formuliert!