PureBoard

Du kannst schon die Datasection verändern so mit PokeB usw., aber dann bewiehen sich diese Änderungen nur auf die Daten die in den Arbeitsspeicher geladen wurden. Beim Neustart ist soweit ih weiß alles wieder beim alten.

@PMV
Danke, das Beispiel von Mischa kenne ich schon.
Der hat wirklich was drauf.
Wäre schön, wenn ich PureBasic auch mal so beherrschen würde.

@unix
So etwas geht also in PureBasic auch?

Ich habe vor etwa 15 Jahren mal mit PowerBasic 3.2 für DOS ein Programm geschrieben, bei dem ich ein Passwort verschlüsselt in der EXE-Datei speichern und verändern konnte. Die EXE-Datei hatte ich im BINARY-Modus geöffnet, mit GET$ und PUT$ konnte man lesen und schreiben und mit SEEK den Dateizeiger setzen. Auch LOC und LOF gab es damals schon, also ähnlich wie heute in PureBasic. Ich weiß nur nicht mehr, wie ich damals die Position des Passwortes ermittelt habe.
Scheiß Alzheimer! Ich werde alt.

Na ja, vielleicht funktioniert ja die Funktion ReplaceFileData() von FroggerProgger. Er hat mir vorhin ein einem anderen Forumsthema ein Beispiel gepostet. Dann wäre mein Problem gelöst.
Vielen Dank für deinen Tipp!

Froggerprogger hat geschrieben:Ja Blackskyliner, das möchte ich sehen. Insbesondere mit dem String... und mit dem Überschreiben einer geöffnete Exe...

Ok, bin davon ausgegangen, dassers mit ner anderen ändern will, sorry! Aber das andere, das ändern, muss gehn, hatte das schonmal hinbekommen

Klar, eine geöffnete EXE kann man nicht überschreiben.

Mit einem anderen Denkansatz kann man aber trotzdem die Einstellungen in der DataSection der gleichen EXE ändern.

1.) Nach dem Start erstellt man sich eine Arbeitskopie seiner laufenden EXE-Datei (z.B. mit OpenFile("Testprogramm.exe", "Testprogramm.$$$")

2.) In der Kopie Testprogramm.$$$ können die Strings ausgetauscht werden (z.B. mit ReplaceFileData() von Froggerprogger).
Ein kleines Beispiel zum Aufruf siehe hier:
http://forums.purebasic.com/german/view ... c&start=10
Für InputFile$ und OutPutFile$ wird Testprogramm.$$$ eingegeben.
Suchen$ und Ersetzen$ müssen die gleiche Länge haben, sonst ist die Zieldatei kaputt und natürlich muss Suchen$ in Testprogramm.$$$ zu finden sein.

3.) Kurz vor Programmende erzeugt und startet man eine kleine Batchdatei, die die laufende EXE löscht und anschließend die temporäre Arbeitsdatei Testprogramm.$$$ wieder in Testprogramm.exe umbenennt.
Die Batchdatei kann natürlich die laufende EXE nicht löschen.
Daher muss in der Batchdatei der Löschbefehl in einer Scheife ausgeführt werden, bis die Testprogramm.exe geschlossen ist.
Ein Beispiel, wie man eine laufende EXE-Datei löscht findet sich auch im Codearchiv.

Auf diese Weise könnte man also auch die eigene EXE aktualisieren und bräuchte keine Ini-Datei oder Registry-Einträge.

Für meinen Bedarf genügt es jedoch, die EXE mit einer anderen EXE-Datei zu ändern und das kann ich prima mit ReplaceFileData() erledigen. Vielen Dank Froggerprogger! Das war genau die Funktion, die ich gebraucht habe
Ich hoffe, sowas wird mal in einem PureBasic-Update als Befehl eingebaut.
Eine ReplaceMemData() zum Suchen und Ersetzen im Speicher würde ich mir in einem PureBasic-Update auch noch wünschen

unix hat geschrieben:Du kanst mit BinaryInclude eine datei Includieren und dann mit Read und WriteString belibig ändern.

Code: Alles auswählen

openfile(0,?MyFile) ;könnte wenn nicht
openfile(0,"MyFile")

readstring(...
writesting(...

datasection

MyFile:
 binaryinclude "MyFile"

enddatasection

oder so ähnlich.
Musste mal schaun

Geht definitiv nicht Wär ja auch unlogisch, weil die Executable kann nur beschrieben werden wenn sie nicht läuft. Außerdem wird bei OpenFile(ID, Filename.s) ein String erwartet, und woher soll das Program bei "MyFile" wissen, dass du eine Adresse(die es ohnehin nicht mit dem Synonym "MyFile" verbindet, denn so einen Schwachsinn gibt es nur in ScriptSprachen) im Program meinst?

Ich habe den Lösungsansatz von unix nicht weiter verfolgt, weil ich schon zwei alternative Lösungsmöglichkeiten von ts-soft und Froggerprogger hatte.

Schade, dass man in PureBasic das laufende EXE-Programm nicht verändern kann.

In PowerBasic für DOS konnte man die eigene EXE direkt ändern.
Ich habe mein Paßwortprogramm das ich 1992 geschrieben habe wieder gefunden.

Hier ein paar Auszüge aus dem Code: Als Suchtext habe ich "Ø=" (Durchmesserzeichen, ASCII 157, nicht mit 0 verwechseln) verwendet, um die Position des Paßwortes in der PW.EXE zu finden. Diese Zeichenfolge kam sonst in der fertigen EXE nicht mehr vor.
Das vorgegebene Paßwort "GEHEIM" habe ich in zwei Zeichen verschlüsselt (hier zufällig "[p") und als Startpaßwort vorgegeben.
Zur Verschlüsselung habe ich einfach die Quersumme der ASCII-Zeichen des Paßwortes gebildet und mit zwei Rechenansätzen zerlegt.

In PowerBasic wurden die Strings am Ende der EXE gespeichert und weil die Stringlänge auf ca. 32000 Zeichen begrenzt war, habe ich einfach die letzten 32000 Zeichen der PW.EXE in einen String eingelesen, diesen mit instr nach Ø= durchsucht und die nachfolgenden zwei Zeichen mit der Umrechnung des eingegebenen Paßwortes verglichen.

Nach Änderung des Paßwortes durch den Benutzer konnte man den neuen Paßwortcode wieder direkt in die PW.EXE schreiben. Die Position ist ja noch vom Suchen bekannt.

Wichtig war nur, dass man die Zeichen in den durch den Platzhalter reserierten Platz schrieb. Ein Schreiben darüber hinaus hätte die PW.EXE beschädigt und evtl. zum Absturz gebracht.

Ich PowerBasic für DOS konnte man also wirklich die gestartete PW.EXE selbst ändern.
In PureBasic geht es nur mit Tricks.

Es ist schon interessant, wenn man sich nach so vielen Jahren die eigenen Quelltexte betrachtet und sieht, welche geistigen Klimmzüge man damals unternommen hat.
Heute würde man das garantiert anders und sicherer lösen, aber damals, ohne Vorlagen hat man eben nur programmiert, was einem gerade einfiel.

Dass man eine geöffnete EXE-Datei nicht während der Laufzeit ändern kann ist allerdings keine Schwäche von PureBasic, sondern dem Datei- und Betriebssystem zuzuschreiben. Unter DOS war das alles noch simpler. Dafür gabs da kein Multitasking, so dass man gar nicht Gefahr laufen konnte, dass z.B. ein anderes Programm die parallel laufende EXE verändert.