ReadProcessMemory() im eigenen Prozessraum?



  • Die Frage ist ja auch hohl wie Blumenkohl



  • Frage10 schrieb:

    Du hast die Frage wohl nicht verstanden.

    Alles , was in dem Speichbereich deines Prozesses liegt, kannst du mit Pointern ansprechen. Dazu sind sie ja da.



  • Ja stimmt, war wohl etwas übervorsichtig, so wie immer 🙄



  • wenn du deinen code einschleusen willst und der dann auf deinen prozess zugreifen
    will, musst du ReadProcessMemory nehmen, da der code ja jetzt im prozessraum
    den anderen prozesses liegt 😉



  • moep: die Frage bezog sich, glaub ich, auf den eingeschleusten Code.

    Allerdings freu' ich mich schon auf das tolle Programm.... Wahrscheinlich is deine Zeit einfach wertvoller als meine.



  • Nein, nochmal, genauer...

    Eine DLL wird in einen Prozessraum gemapped, muss der Code der DLL dann ReadProcessMemory() verwenden weil in eben diesem fremden Prozess gerade ein anderer Thread auf den Speicher schreiben könnte...
    Kenne mich mit der tieferen Materie nicht so gut aus, wieviele Zyklen das jetzt braucht, ob mein Code dann Hälfte/Hälfte alten/neuen Wert auslesen würde zB und RPM() verhindert es weil es wartet und atomic ist.. kA

    Gibt's ein gutes Buch über all so Dinge?



  • der Prozeß ist ja nun nicht mehr fremd 🙂

    Die einzige Aufgabe von RPM ist, Speicher aus einem anderen Prozeß zu lesen. Wenn dein DLL in dem fraglichen Prozeß ausgeführt wird, brauchst du's nicht.

    So, und jetzt guck' Dir bitte Speicherverwaltung und Ressourcen unter Windows an.



  • Ja aber... du hast meine Frage nicht wirklich beantwortet und die hat glaube ich nix mit Speicherverwaltung zu tun...
    Der Prozess ist insofern noch "fremd" da ich keine Kontrolle über die anderen Threads habe und die auf den Speicher schreiben könnten während ich lesen möchte...

    Wenn ich zB. 1MB Speicher lese, und knapp vor dem Lesen ein Thread beginnt diesen Speicher zu überschreiben, habe ich dann doch Teils neue Werte, teils alte Werte?!
    Verhindert RPM() dies nicht?

    MfG



  • man wie oft denn noch, DAS EINE HAT NIX MIT DEM ANDEREN ZU TUN. WENN DU EINEN SPEICHERBEREICH HAST, DEN MEHRERE THREADS POTENTIAL GLEICHZEITIG SCHREIBEN KÖNNEN, MUSST DU ENTSPRECHENDE SYNCHRONISATIONS PRIMITIVEN BENUTZEN, UM DIES ZU KOORDINIEREN. DAS IST ABER IN DEINEM EIGENEN PROZESS GENAU DAS GLEICHE. WAS SOLL HIERBEI ReadProcessMemory BRINGEN??!??! LIES HALT MAL DIE MSDN ANSTELLE UNS NOCH 10 SEITEN MIT MÜLL ZU NERVEN. ICH HAB DEINE FRAGE VERSTANDEN BTW.



  • Frage10 schrieb:

    Gibt's ein gutes Buch über all so Dinge?

    ja.
    Windows Via C/C++ | ISBN: 0735624240



  • asdca schrieb:

    WENN DU EINEN SPEICHERBEREICH HAST, DEN MEHRERE THREADS POTENTIAL GLEICHZEITIG SCHREIBEN KÖNNEN, MUSST DU ENTSPRECHENDE SYNCHRONISATIONS PRIMITIVEN BENUTZEN, UM DIES ZU KOORDINIEREN.

    Kann ich aber nicht, da es wiegesagt ein fremder Prozess ist in den ich eine DLL einbette. Ich hab doch nicht die critical section Objekte oder sonstwas von der fremden Anwendung, somit kann ich nicht synchronisieren.



  • Frage10 schrieb:

    Kann ich aber nicht, da es wiegesagt ein fremder Prozess ist in den ich eine DLL einbette. Ich hab doch nicht die critical section Objekte oder sonstwas von der fremden Anwendung, somit kann ich nicht synchronisieren.

    Man kann Threads schlafen legen. Wenn alle schlafen, kann dir niemand über die Daten schreiben, ist doch ne gute Synchronisation 🙂



  • ReadProcessMemory führt keine Synchronisation durch. Punkt.

    SuspendThread ist (fast) überhaupt keine Synchronisation - dir pfuscht zwar keiner mehr zwischenrein, aber da Du nicht weist wann Du den Thread schlafenlegst, kann sich im Speicher inkonsistenter Müll befinden.


Anmelden zum Antworten