Klotzkopp

Mir erschließt sich der Sinn zwar nicht, aber was soll's. Das ist ebenso willkürlich wie falsch. Du kannst nicht am Speicherinhalt erkennen, was belegt ist. Die MemoryManagement-API gilt, soweit ich weiß, nur für NT/2000/XP. Du könntest mal im Windows 98 DDK nachsehen - wenn du das noch bekommst. Offiziell wird es von MS nicht mehr supportet, und in der MSDN Subscription ist es auch nicht mehr drin.

Ja, da irrst du dich. Du beschreibst - mehr oder weniger - die Auslagerungsdatei. Ich rede hiervon: http://de.wikipedia.org/wiki/Virtueller_Speicher Das ist das grundsätzliche Problem. Bei Betriebssystemen, die virtuellen Speicher anbieten - und Windows 98 gehört dazu -, haben die Adressen, die in den Prozessen benutzt werden, nichts mit physischen Speicheradressen zu tun. Du kannst einem Zeiger nicht ansehen, ob er gerade irgendwo ins physische RAM, eine gemappte Datei oder die Auslagerungsdatei verweist. Nein, unter NT/2000/XP hast du gar keine Möglichkeit, "unter" die Schicht des virtuellen Speichers zu kommen, ohne einen Treiber zu schreiben. 9x/ME hat da noch Lücken, weil es letztendlich immer noch auf MS-DOS basiert.

Doch, das brauchst du. Ich glaube, du weißt nicht genau, wovon du redest. Anscheinend wirfst du die Begriffe Cache, Stack und Register wild durcheinander. Diese Funktion liefert die auch die Heaps der Prozesse, das ist der belegte virtuelle Speicher. Es steht dir frei, etwas schnelleres zu schreiben. Aber dazu müsstest du dich ziemlich tief in die interne Funktionsweise von Windows einarbeiten. Wenn du Ernst genommen werden möchtest, lässt du bitte solche Kindereien. Es ist richtig, dass der Speicherschutz unter 9x/ME nicht so streng ist wie bei NT/2000/XP. Das bedeutet aber nicht, dass es dort spezielle APIs gibt, die diese Schwächen ausnutzen. Mein persönlicher Eindruck: Wenn du schon seit 15 Jahren "codest", dann hast du damit angefangen, bevor du lesen konntest. Mal ganz abgesehen davon, dass 15 Jahre eine stolze Leistung sind, für ein Betriebssystem, das noch keine 7 Jahre alt ist.

Ich weiß nicht, was du mit "CPU interner Stack" meinst. Threads haben Stacks, nicht die CPU. Weißt du, was virtueller Speicher ist? Dann fang mal bei CreateToolhelp32Snapshot an zu lesen.

Falls du nicht gerade von MS-DOS redest: gibt es nicht nur einen, sondern jede Menge Stacks. Es gibt auch - zumindest bei Betriebssystemen, die virtuellen Speicher anbieten - nicht die Adresse. Kommt drauf an, für welches Betriebssystem das sein soll. Das kannst du vergessen, zumindest bei aktuellen Desktopbetriebssystemen. Ohne dir zu nahe treten zu wollen: Ich glaube, deine Vorstellungen vom Speichermanagement basieren noch auf DOS Einfach wird das sicher nicht. Der Begriff "lutschen" ist mir im Zusammenhang mit DLLs noch nicht begegnet. Was bedeutet das?

Wie ich schon hier geschrieben habe, sollst du, wenn du CallNextHookEx aufrufst, den Rückgabewert dieses Aufrufs zurückgeben. Außerdem sollst du nur dann 0 zurückgeben, wenn du einen guten Grund dafür hast, dass andere Hooks diese Nachricht nicht sehen sollen. Die Zuweisung an lParam ist überflüssig. Darüber hinaus wirst du wohl den Debugger bemühen müssen. Möglicherweise kann man aus den Werten in Nachricht->lParam etwas folgern.

Die generierten Dateien heißen mysqlpp.dll und mysqlpp.lib. Meinst du die? Dann schick mir eine PM mit deiner E-Mailadresse. So schwierig war das übrigens nicht

Eine Anmerkung am Rande: Es ist ziemlich unhöflich, einfach den Code hinzuklatschen, ohne irgendeine Fehlerbeschreibung. Du könntest zumindest das auftretende Verhalten beschreiben. Noch besser wäre es, wenn du nicht benötigte Teile aus dem Code entfernt hättest. Das Problem habe ich aber auch so gefunden: strlen ermittelt die Länge des Strings über die Nullterminierung. Du setzt aber nirgendwo eine. Das brauchst du auch nicht, weil du ja immer weißt, wo das Wort aufhört. Der zweite Parameter von reverse muss jedenfalls der Zeiger auf den Wortanfang + Länge des Wortes sein. Du musst entweder die Länge anders ermitteln oder deine Worte nullterminieren.

reverse(wort, wort + strlen(wort)); [/code] Du brauchst dafür <algorithm>. Und natürlich <cstring> für strlen.

Stereotypen erweitern Metaklassen. Das ganze läuft eine Abstraktionsebene über den Klassen ab.

Ich denke, das Hauptproblem ist die Suche in m_Signs. Du benutzt IndexOf, das benutzt eine lineare Suche. Da m_Sign sortiert ist, könntest du statt dessen eine binäre Suche benutzen, die ist um einiges schneller. Eine andere Möglichkeit wäre, m_Signs als Array von bool-Werten aufzusetzen, und diejenigen Positionen mit True zu kennzeichnen, die als Zeichen auftauchen können. Das hätte den Vorteil, dass du gar nicht mehr in m_Signs nach einem Zeichen suchen müsstest, sondern direkt über den Index gehen könntest. Warum benutzt du einen StringBuilder, statt den String selbst zu ändern? Das könnte einiges an unnötigen Kopieraktionen ersparen.

Am einfachsten schreibst du in eine Datei oder in die Registry, wann das Programm zum ersten Mal gestartet wurde. Beim Start prüfst du dann diesen Wert, und verweigerst gegebenenfalls die Ausführung. Die Frage ist, ob das deinen Ansprüchen genügt. Wie ernst ist dir dieses Vorhaben? Es gibt viele Möglichkeiten, so etwas umzusetzen, und jede kann letztendlich umgangen werden, es ist nur eine Frage, wie schwer man es dem "Cracker" macht. Generell kann man sagen, dass sicherere Lösungen den Aufwand für dich - und irgendwann auch für den Benutzer der Software - nach oben schrauben.

Mal zwei Beispiele: int foo() { threadArgs ta; CreateThread(&bar, &ta); // Stark vereinfacht // <- hier wird ta zerstört } int bar(void* param) { threadArgs* ta = (threadArgs*)param; // <- gibt es das Objekt überhaupt noch? }[/code] Du kannst hier nicht sicher sein, dass die lokale Variable ta in foo überhaupt noch existiert, wenn du im Thread bar die Adresse rausholst. Das ist genauso böse wie das Zurückgeben der Adresse einer lokalen Variablen. 2. Beispiel [code]class someclass { threadArgs m_ta; int foo() { CreateThread(&bar, &m_ta); // Stark vereinfacht m_ta.m_intMember++; } }; int bar(void* param) { threadArgs* ta = (threadArgs*)param; int wichtig = ta->m_intMember; // <- Welcher Wert landet hier? }Hier ist die Lebensdauer kein Problem. Aber du kannst nicht wissen, ob zuerst im someclass::foo der int-Member erhöht, oder im Thread bar ausgelesen wird. Dieses Problem tritt immer dann auf, wenn du die Threadparameter ändern könntest - wie in deinem Fall. Und es ist natürlich Quatsch, Adressen von globale Variablen als Threadparameter zu übergeben. An globale Variablen kommst du ja auch so ran. Wenn du nicht ganz sicher bist, dass das Parameterobjekt lange genug lebt und unveränderlich ist - zumindest bis der Thread eine Kopie anlegen konnte - solltest du entweder Synchronisierungsobjekte benutzen oder die Parameter für jeden einzelnen Thread auf dem Heap anlegen.

Drei Anmerkungen: Wie ist ta deklariert? Ist das eine lokale Variable? Falls ja, könnte das zu den oben erwähnten Problemen führen, falls du mal nicht auf das Ende des Threads wartest. Zweitens: Wenn du Zeiger in deiner threadArgs-Struktur benutzt, gilt für die Lebensdauer der Objekte, auf die diese Zeiger verweisen, das gleiche wie für die Struktur selbst. Und drittens ist ein Thread ziemlich sinnlos, wenn du gleich nach dem Starten auf das Ende wartest. Oder war das nur ein Beispiel?

Du kannst jeden beliebigen Zeiger in den Thread reingeben, und dann im Thread durch einen passenden Cast wieder rausholen. Du musst nur darauf achten, dass die Lebensdauer des Objekts, dessen Adresse du übergibst, lang genug ist. Die Adresse eine Autovariablen zu benutzen, ist also meist eine ziemlich schlechte Idee.

Zum Beispiel. Oder std::reverse, wenn du keine Schleifen magst.

Das geht nicht. Wenn du das so ausgeben willst, musst du den Inhalt des Arrays vorher umdrehen. Pointer auf Pointer ist in diesem Zusammenhang totaler Blödsinn.

Wäre durchaus möglich. Genau weiß ich das aber auch nicht. Die Dokumentation ist diesbezüglich ziemlich dürftig

Was meinst du denn mit "eingepflanzt"?

Das beschriebene Verhalten passt aber nicht zu deinem Code. Diese Zeile TempSrNr = Mid(TempSrNr, i + 1) bewirkt, dass du bei jedem Durchlauf vorne ein Zeichen mehr abschneidest, d.h. beim ersten Durchlauf das erste, danach die ersten beiden usw. Das fällt nicht auf, wenn die Anzahl der führenden Buchstaben 1, 3 oder 6 ist. Aber in allen anderen Fällen schneidest du Zahlen mit ab. Um es kurz zu machen: Das muss entweder TempSrNr = Mid(SrNummer, i + 1) heißen, oder TempSrNr = Mid(TempSrNr , 2)

Genau. Die Eingabe landet in der Variablen antwort, und die wird als Dateiname verwendet. Schreib doch bitte mal vor die Zeile (ziemlich weit unten) set objFile= datei.OpenTextFile(antwort, 2) folgendes: datei.DeleteFile antwort

Ich habe die Formel nochmal überarbeitet, jetzt sollte sie wie gewünscht funktionieren: =VERKETTEN(TEIL("ABCDEFGHIJKLMNOPQRSTUVWXYZ"; (ZELLE-1)/26+1;1);TEIL("ZABCDEFGHIJKLMNOPQRSTUVWXY"; REST(ZELLE;26)+1;1))

Ist das denn der Dateiname, den der Benutzer in der Inputbox eingibt? Falls nicht, ist das das falsche Script.

Um welche Datei handelt es sich denn? Die, die der Benutzer angibt? Oder helpmeout.txt? http://msdn.microsoft.com/library/en-us/script56/html/8575e5c4-dec5-48e7-92a2-790cac708c7f.asp The iomode argument can have any of the following settings: Constant Value Description ForReading 1 Open a file for reading only. You can't write to this file. ForWriting 2 Open a file for writing. ForAppending 8 Open a file and write to the end of the file.