Hi all!

Wer von euch weiss, wie ich etwas in eine von mir gewählte speicheradresse schreiben kann?

hab die funktionen: memcpy, memmove, memset und dosmemput gefunden, aber verzweifle dran.

auf was muss ich denn achten...

oder gibt es bessere funktionen?

thx

Hi koma,

memcpy() kopiert Speicherinhalte.

memmov() tut das Gleiche, auch wenn die Speicherbereiche sich ueberlappen.

strcpy() kopiert ganze Strings (null-terminiert).

strncpy() kopiert Teilstrings.

memset() setzt die Bytes eines Speicherbereiches auf einen Integerwert.

Funktionen, die mit "dos" anfangen, vergiss am besten ganz schnell wieder.

In allen Faellen braucht man natuerlich Pointer.

Uli

ok, erstmal thx.

kann ich die speicheradresse, denn direkt im parameter der o.g. fkt. angeben?

also das gibts doch net :eek:

edit: warum die fkt. mit dos vergessen, pls erklär mal (will ja was lernen)

[ 25. April 2001: Beitrag editiert von: koma ]

Versuch es mal mit etwas wie:

// 12345 sei die zu bearbeitende Adresse

unsigned char* pAdresse = reinterpred_cast<unsiged char*>(0x12345);

// Speicher verändern ('A' schreiben)

*pAdresse = 'A';

es sollte sich um die programmiersprache 'C' handeln.

ka was du da meinst christian, ich glaub ich hab dich verwirrt.

Original erstellt von koma:

<STRONG>es sollte sich um die programmiersprache 'C' handeln.

ka was du da meinst christian, ich glaub ich hab dich verwirrt.</STRONG>

*gacker* ja, der Christian schiesst mit Kanonen auf Spatzen; wenn ich das richtig interpretiere, schlaegt er Dir ein Funktionentemplate vor, wobei ich aber nicht weiss, wo dieses implemetiert sein soll.

In c geht das ganz einfach mit einer Typumwandlung (cast), etwa so:

int* p= (int*) 12345;

oder direkt in einer Funktion:

setzeWertBeiAdresse( (int*) 12345 , wert);

*kopfkratz* Irgendwie beschleicht mich manchmal das Gefuehl, dass beim Direkteinstieg in c++ gewisse Handicaps entstehen.

Uli

@uli

bei dem reinterpret_cast<...>(...) aus christians würde ich eher von casten reden. so soll man es nämlich unter c++ auch schaffen können. ist also ähnlich dem (..) aus alten c zeiten.

*kopfkratz* irgendwie beschleicht mich das gefühl, das beim umstieg auf c++ leichte handicaps entstehen.

Original erstellt von maddin:

<STRONG>@uli

bei dem reinterpret_cast<...>(...) aus christians würde ich eher von casten reden. so soll man es nämlich unter c++ auch schaffen können. ist also ähnlich dem (..) aus alten c zeiten.</STRONG>

Ja, so in etwa. Fuer das Beispiel hier kann man beide nehmen. Allgemein sind C-casts "haerter". Wenn zur Compiletime festgestellt wird, dass nicht unbedingt eine Katastrophe passiert, geht das glatt durch und ist dementsprechend gefaehrlich. C++ stellt verschiedene Casts mit verschiedenen Einschraenkungen zur Verfuegung, vor allem, um das Debuggen zu erleichtern. Syntaktisch sind sie Templates. Nun vermag ich aber nicht einzusehen, warum man den Compiler damit belasten sollte, weil ja der reinterpret_cast sowieso der haerteste ist; da kann ich auch gleich den von C nehmen und spare vermutlich Code. Man muss halt sicher sein, dass die constante Adresse gueltig ist. Aber eigentlich ist es fast immer schlechter Stil.

Irgendwie beschleicht mich das Gefuehl, dass C und C++ beide beim Casten zu Handicaps fuehren koennen.

Uli

casten ist, wenn es nicht unvermeidlich ist immer schlechter stil.

zu den cast- operatoren. sicher ist der von c schon ziemlich hart, aber bei einigen sachen funzt es damit bei mir nicht. mit c++ mitteln dagegen schon.

ps: das verrückteste ist doch der const_cast<...>(...) oder nicht

Hallo zusammen!

Sorry, konnte leider nicht mehr am Wochenende antworten, aber zum Thema:

Tatsächlich wird casten allgemein als "Designfehler" oder einfach als "unschön" angesehen, allerdings nur im High-Level-Code. Eine Speicheradresse explizit anzusprechen ist aber eindeutig Low-Level, und da kommt man ohne Casts nicht hin und muß wohl "mit Kanonen auf Spatzen schießen" . Tatsächlich sollen auch die C++-Casts sicherer sein als normale C-Casts, ich selbst habe allerdings zu wenig Erfahrung mit diesen Dingern, darum möchte ich dazu keine Meinung abgeben. Sorry, falls ich für unnötige Verwirrung gesorgt habe.

also ich hab mir das heute nochmal angeguckt und folgende zeilen solltet ihr euch mal angucken:

#include <stdio.h>

#include <string.h>


main()

{                                   

  char zeichen[8];

  int *x;

  int *adresse = (int*)0xB8003998;


  *zeichen = 'A';


  x = memcpy(adresse, zeichen, sizeof(zeichen));


  getch();                  

}

und jetzt sagt mir bitte warum das nicht geht, ich wills raffen und nicht rumprobieren, aber ich brauche HILLLLLFEEEE!! ;-(

bittebittebitte!!!

Original erstellt von koma:

<STRONG>

...ich wills raffen und nicht rumprobieren, aber ich brauche HILLLLLFEEEE!!

</STRONG>

Kommt ja schon...

Du benutzt memcpy() falsch! Das sizeof-Macro wendest Du auf einen POINTER an. Richtig waere, es auf den Datentyp, auf den der Pointer zeigt, anzuwenden.

Uli

hmm, ok thx, fehler nummer 2 gefunden, fehler nummer 1 finde ich nicht ---> bricht immer noch ab.

woran liegt das nur? :eek: hat sich mal jemand die mühe gemacht es auszuprobieren?

ansonsten: ULI ICH BRAUCH MEHR INPUT

Original erstellt von koma:

<STRONG>

ansonsten: ULI ICH BRAUCH MEHR INPUT </STRONG>

Nee, WIR brauchen mehr Input. (Ohne praezise Fehlerbeschreibung keine Fehlerdiagnose; ist doch klar, oder?) Allgemein kann ich zu dem Beispiel auch nur sagen, dass der Ausgang ungewiss ist, wenn man willkuerlich ein Speicherbyte OxIRGENDWO ueberschreibt. Bei mir (ich hab es ausprobiert), schmiert das ganze Programm ab. Statt dem sizeof kannst Du einfach auch die Anzahl der zu kopierenden Elemente angeben, also 1.

Uli

sorry, fehlermeldung: "Program has received signal: SIGABRT, Aborted"

also nix richtiges

die adresse liegt im speicherbereich der grafikkarte und es MUSS klappen...

wenn ich halt wüsste warum er abbricht...

Original erstellt von koma:

<STRONG>

die adresse liegt im speicherbereich der grafikkarte und es MUSS klappen...

</STRONG>

Dein Betriebssystem ist anderer Meinung, sonst hatte es dem Programm nicht das Signal geschickt, sich zu beenden, was es dann auch getan hat.

Speicherschutz nennt man das. Soll verhindern, dass gute Programmierer aus Versehen oder weniger gute mit Absicht das Geheimnisprinzip umgehen, was schon etwas mehr als eine Stilfrage ist. Fuer solche Adressbereiche ist die Treiberebene zustaendig; einzelne Programme haben da nichts zu suchen.

Damit ist es hoechstwahrscheinlich kein C-Problem mehr, sondern ein OS-Problem.

Uli

naja, ich programmier ja noch nicht sooo lange, aber ich weiss ja was ich tue. nur mein betriebssystem vertraut mir nie

hmpf, ich werde schon noch ne möglichkeit finden und werde sie hier posten.

jetzt mach ich erstmal was anderes bis mich der blitz trifft und ich eine schlaue idee hab.

dennoch thx

ich würde vielleeciht mal auf win 9x umsteigen. da kann man sich sein system viel besser zerstören.

oh mann, wieso denn zerstören???????????????????????? :confused: :confused: :confused: :confused: :confused: :confused:

WENN er das ausführen WÜRDE, WÄRE das ergebnis, dass er ein 'A' unten rechts auf dem screen anzeigen WÜRDE!!!!

problem an der sache ist bloß, das du das bei nt/2k nicht darfst. von wegen schützen der hw vor übereifrigen codern.

klar, das versteh ich ja auch, btw hab ich aber w98, aber das wills halt auch nicht..

aber zerstört hätte ich trotzdem nix

LOAD "WIN98",8,1

dann könnte es noch daran liegen, das ein anderes programm den von dir gewollten speicherbereicht schon für seine aufgaben reserviert hat. dann kann man da glaubich auch nicht unter win9x drauf zugreifen.

hmmm.. also da es ja der speicher der grafikkarte ist, wäre es ja kein problem den trotzdem zu ändern, oder vertue ich mich da???

selbst wenn er belegt wäre...

hab ne neue fehlermeldung:

"Program has received signal: SIGSEGV, Segmentation fault"

kann damit jemand was anfangen?

das lustige ist, ich hab nix verändert...

:eek: