Entwickler-Ecke :: Thema anzeigen - EXE-Datei nach einmaligem Start löschen

Entwickler-Ecke

Dateizugriff - EXE-Datei nach einmaligem Start löschen

Dude566 - Mi 28.01.09 17:54
Titel: EXE-Datei nach einmaligem Start löschen

Ich möchte dass mein Programm nur einmal ausgeführt werden kann, also kein Kopierschutz.

Die Anwendung soll am besten beim OnClose gelöscht werden, den Pfad für den Ordner bekomme ich mit ExtractFilePath(ParamStr(0));.

Dann muss ich ja nur noch den Dateinamen anhängen, und dann irgendwie löschen.

Doch wie kann ich die Datei am besten löschen?
Ich habe gesucht, aber nichts brauchbares gefunden.

PS: Mit Deletefile hat es nicht funktioniert.

Moderiert von matze: Delphi-Tags hinzugefügt
Moderiert von Narses: Titel geändert.

JayEff - Mi 28.01.09 17:57

Moment moment. Du willst, dass dein Programm nur einmal ausgeführt wird, und wenn der User es wagen sollte, es zweimal auszuführen, möchtest du das Programm von der Festplatte löschen? :shock: Ich glaube, du verstehst da was falsch ...

Edit: Klar dass DeleteFile nicht funktioniert: Ein laufendes Programm zu löschen sollte eigentlich nicht drin sein :)

Ich vermute mal, dass du nur willst, dass eine zweite Instanz des Programms wieder geschlossen wird. Schau dir dazu Suche in: Delphi-Forum, Delphi-Library

ONEINST an.

Dude566 - Mi 28.01.09 18:00

Nein, es ist ja nur eine Programmdatei, das hauptsächliche ist ja noch da.

Also einen Lösungsvorschlag?

JayEff - Mi 28.01.09 18:04

Also wenn du wirklich dein Programm von der Platte löschen möchtest (Die Exe-Datei die gerade läuft), dann musst du das tun, nachdem dein Programm beendet wurde. Das kannst du erreichen, indem du eine Bat-datei erstellst mit del meinprogram.exe und diese ausführst, bevor du dein programm dann beendest. Aber warum um in aller Welt willst du das tun? :mrgreen:

Edit: Ah nun verstehe ich. Du willst, dass dein Programm auf einem Rechner nur einmal (nicht einmal *gleichzeitig*, sondern tatsächlich nur 1 mal) ausgeführt werden kann. Das mit dem Löschen ist zwar eine Idee, aber wenn ich das Programm dann einfach nochmal runterlade, dann kann ich es ja wieder starten.

Man könnte einen Registry-Eintrag schreiben, der ein erneutes Starten nicht erlaubt (vor Application.CreateForm dann abfragen ob dieser gesetzt ist), was aber unschön ist, da dir solch Programmierstil auf dauer die Registry zumüllt.
Man könnte eine Datei im Anwendungsdatenverzeichnis ablegen, was aber auf's gleiche hinauskommt. Mehr fällt mir nicht ein... :(

Dude566 - Mi 28.01.09 18:11

Ja auf das mit der Batch kam ich eben auch, hat bis jetzt noch nicht geklappt.

Das mit der Registry möchte ich auch nicht, am System soll nicht rumgefummelt werden.

jaenicke - Mi 28.01.09 19:05

Dude566 hat folgendes geschrieben :

Ja auf das mit der Batch kam ich eben auch, hat bis jetzt noch nicht geklappt

Du musst eine Schleife in der Batchdatei machen. Wenn die Datei existiert wieder zurückspringen vor den Löschbefehl. Dann läuft das so lange bis das Programm beendet ist und es die Datei löschen konnte. ;-)

MSCH - Mi 28.01.09 20:39

das klingt alles grausam.
Willst du einen Virus programmieren :-?
Welch Zweck sollte das wohl haben?

Egal:
erstelle beim Programstart (wenn ohne Parameter) eine Batch-Datei
Rufe die Batchdatei via ShellExecute auf und verlasse dein Program
diese Batchdatei ruft dein Program auf (mit Parameter)
Programm startet (mit Parameter) und läuft

z.b. MeinProg.Exe

c:>\meinprog.exe
programm stellt fest, dass es ohne Parameter gestartet wurde und erstellt eine Batch-Datei welche enthalt

@echo off
meinprog.exe geheimerParameter
delete meinprog.exe

und ruft anschließend die Batchdatei auf und beendet sich.

:-)msch

Dude566 - Do 19.03.09 19:30

@jaennicke : Wie geht das mit der Schleife, habe mit Batch Dateien keine großen Erfahrungen.

@MSCH: Nein ich will keinen Virus machen, weis garnet wieso du mir das jetzt unterstellst.

JayEff - Do 19.03.09 19:40

Dude566 hat folgendes geschrieben :

@jaennicke : Wie geht das mit der Schleife, habe mit Batch Dateien keine großen Erfahrungen.

Naja eine schleife...

Quelltext

1:
2:
3:

:schleife
del asd.exe
if exist asd.exe goto schleife

So vielleicht? :mrgreen:

Dude566 - Fr 20.03.09 18:08

Das mit goto kannte ich ja, aber das mit if exist nicht.

Danke werde es ausprobieren. ;)

Edit: Funktioniert nicht wie gewünscht, es schreibt den Befehl immer weiter, aber die Datei wird nicht gelöscht.

Quelltext

1:
2:
3:
4:

:schleife
del C:\Dokumente und Einstellungen\Anwender\Desktop\test\Project2.exe
if exist Project2.exe goto schleife
exit

jaenicke - Fr 20.03.09 18:36

Die Pfadangabe ist falsch...

Quelltext

1:	del "C:\Dokumente und Einstellungen\Anwender\Desktop\test\Project2.exe"

Und wenn die nötig wäre, warum fehlt die dann bei dem exist?

Wenn du die Batchdatei mit dem richtigen Verzeichnis als Arbeitsverzeichnis startest, dann kannst du dir die Pfadangabe auch sparen...

Dude566 - Fr 20.03.09 18:43

Achso die wird ja im selben Verzeichnis wie die Anwendung erstellt, dann geht es auch ohne Pfad.

Edit: Jetzt funktioniert es. Danke für die Hilfestellungen. ;)

jaenicke - Fr 20.03.09 18:48

Dude566 hat folgendes geschrieben :

Achso die wird ja im selben Verzeichnis wie die Anwendung erstellt, dann geht es auch ohne Pfad.

In der Batchdatei ja, beim Aufruf der Batchdatei z,B. mit ShellExecute darf die Angabe des Arbeitsverzeichnisses nicht fehlen.

Sonst muss man deine Exe nur mit einem anderen Arbeitsverzeichnis starten und schon funktioniert das nicht mehr, weil AFAIR dann das Arbeitsverzeichnis der startenden Exe benutzt wird.

Dude566 - Fr 20.03.09 19:02

Ja das ist schon klar, das sie beide im selben Verzeichnis sein müssen wenn die Batch die Exe löschen soll.

Das Ausführen der Batch erfolgt aber nicht mit einer genauen Pfadangabe, habe lediglich den Dateinamen der Batch angegeben.

Reicht völlig aus solange beide im gleichen Verzeichnis sind.

jaenicke - Fr 20.03.09 19:14

Dude566 hat folgendes geschrieben :

Ja das ist schon klar, das sie beide im selben Verzeichnis sein müssen wenn die Batch die Exe löschen soll.

Stimmt nicht, es kommt nur auf das Arbeitsverzeichnis an. Die Batchdatei kann auch im Verzeichnis für temporäre Dateien liegen, das ist vollkommen egal.

Aber das Arbeitsverzeichnis musst du wie gesagt bei ShellExecute auch übergeben. So ist es z.B. falsch und geht nicht bzw. nur durch den Zufall, dass das Arbeitsverzeichnis das Verzeichnis deiner eigenen Exe ist:

Delphi-Quelltext

1:	ShellExecute(Handle, 'open', PChar(ExtractFilePath(ParamStr(0)) + 'test.bat'), nil, nil, SW_SHOWNORMAL);

Richtig wäre es so:

Delphi-Quelltext

1:
2:

  ShellExecute(Handle, 'open', PChar(ExtractFilePath(ParamStr(0)) + 'test.bat'),
    '', PChar(ExtractFilePath(ParamStr(0))), SW_SHOWNORMAL);

Und wenn du deine Batchdatei ins Verzeichnis für temporäre Dateien legst und das Arbeitsverzeichnis auf das deiner Exe setzt, dann funktioniert das trotzdem ohne Pfadangabe in der Batchdatei.

Es ist wichtig, dass du dir das klar machst was passiert, wenn du kein Verzeichnis angibst. Dabei ist es egal ob es eine Batchdatei oder dein Delphiprogramm ist...

Dude566 - Fr 20.03.09 19:32

jaenicke hat folgendes geschrieben :

Dude566 hat folgendes geschrieben :

Ja das ist schon klar, das sie beide im selben Verzeichnis sein müssen wenn die Batch die Exe löschen soll.

Stimmt nicht, es kommt nur auf das Arbeitsverzeichnis an. Die Batchdatei kann auch im Verzeichnis für temporäre Dateien liegen, das ist vollkommen egal.
Wenn das so wäre müsste ich ja bei Shellexecute wieder den ganzen Pfad eintragen.

Aber das Arbeitsverzeichnis musst du wie gesagt bei ShellExecute auch übergeben. So ist es z.B. falsch und geht nicht bzw. nur durch den Zufall, dass das Arbeitsverzeichnis das Verzeichnis deiner eigenen Exe ist:

Delphi-Quelltext

1:	ShellExecute(Handle, 'open', PChar(ExtractFilePath(ParamStr(0)) + 'test.bat'), nil, nil, SW_SHOWNORMAL);

Richtig wäre es so:

Delphi-Quelltext

1:
2:

  ShellExecute(Handle, 'open', PChar(ExtractFilePath(ParamStr(0)) + 'test.bat'),
    '', PChar(ExtractFilePath(ParamStr(0))), SW_SHOWNORMAL);

Das Arbeitsverzeichnis ist aber bei mir bisher immer das gleiche gewesen wie auch das wo die Exe liegt, da die Batch Datei im selben Verzeichnis erstellt wird und auch sofort ausgeführt wird.

jaenicke - Fr 20.03.09 20:09

Dude566 hat folgendes geschrieben :

Das Arbeitsverzeichnis ist aber bei mir bisher immer das gleiche gewesen wie auch das wo die Exe liegt, da die Batch Datei im selben Verzeichnis erstellt wird und auch sofort ausgeführt wird.

Und sobald man in der Verknüpfung zu deiner Exe ein anderes angibst, ist es ein anderes.
Und sobald du einen Öffnen- oder Speichern-Dialog anzeigst, ist es ein anderes, nämlich das im Dialog ausgewählte.
Und wenn es irgendwo explizit mit SetCurrentDir geändert wird, ist es ein anderes.
...

Du kannst dir ja die Demo anschauen, in der Demo zeige ich nur einen Öffnen-Dialog an, und schon klappt das mit dem Arbeitsverzeichnis nicht mehr...
http://www.delphi-library.de/viewtopic.php?p=499701

Dude566 - Sa 21.03.09 12:59

Die Auswahl hat der Anwender ja garnicht.

PS: Danke für den Link, ich verstehe schon was du meinst aber der Pfad kann nun mal nicht im Programm geändert werden.

EDIT:
Habs jetzt doch mit ExtractFilePath noch gemacht, damit auch wirklich kein Fehler in einem dummen Zufall auftreten kann.

Hast ja recht. ;)

matze - Sa 21.03.09 15:12

Noch ein Hinweis am Schluss: Lösch doch bitte in der Batch Datei auch die Batch Datei selber.
Sonst fliegt immer noch so ein blödes Bat File auf der Platte rum...

Dude566 - Sa 21.03.09 15:20

Kann die Datei sich selber löschen?

Gibt es da ein extra Befehl, oder mit dem normalen Del?

jaenicke - Sa 21.03.09 15:54

Die Batchdatei kann sich mit del normal selbst löschen.

Webo - Sa 21.03.09 16:29

Ein kleiner Hinweiß: bei Leuten mit Firewalls, die einem sagt, wenn andere Prozesse/Dateien geöffnet/genutzt werden, bzw. fragt, ob das gestattet ist (so wie ich eine hab), klicken einfach auf "Nicht zulassen" und dein Programm schaut blöd aus der Wäsche ;-)

jaenicke - Sa 21.03.09 16:35

Dass man das extrem leicht umgehen kann, ist doch sowieso klar. Da braucht man keine Firewall dazu.

Aber das ist hier wohl nicht so wichtig.

matze - Sa 21.03.09 17:49

Soweit ich weiß geht das mit dem normalen del, da die Bat Datei ja nicht wirklich ausgeführt wird, sondern nur ein Script ist.

jaenicke - Sa 21.03.09 17:51

Richtig, habe ich ja auch geschrieben. Eine Batchdatei wird nämlich nur beim Start geladen, aber die Datei nicht offen gehalten und gesperrt.

Dude566 - Sa 21.03.09 19:35

jaenicke hat folgendes geschrieben :

Dass man das extrem leicht umgehen kann, ist doch sowieso klar. Da braucht man keine Firewall dazu.

Aber das ist hier wohl nicht so wichtig.

Ist wirklich nicht wichtig, aber aus Interesse: Wie kann man das umgehen?

jaenicke - Sa 21.03.09 19:39

Einfachstes Beispiel: Leg eine del.exe / del.bat / del.com ins selbe Verzeichnis, das sollte schon reichen, zumindest unter alten Windowsversionen. ;-)

Außerdem kann ich eine gleichnamige schreibgeschützte Batchdatei in das Verzeichnis legen. Ich kann der auch die Schreibrechte des aktuellen Benutzers entziehen. Und zack gehts nicht mehr.

Dagegen hilft natürlich ein zufälligerer Name im Verzeichnis für temporäre Dateien. Aber genauso kann man auch weitermachen.

Timosch - Sa 21.03.09 20:28

Und genau deswegen - weil es immer einen Weg gegen wird, etwas zu umgehen - sollte man aufhören mit diesen unsinnigen Versuchen, die Benutzer zu etwas zwingen zu wollen.
Es gab da mal einen wunderschönen Artikel über das endlose Rennen zwischen Endbenutzern und Entwicklern, aber ich finde ihn nicht mehr... :nixweiss:

octonet - Do 26.03.09 01:06

Sorry,

aber das hört sich so an wie:

Alles was ich umsonst erhalten kann nehme ich gerne. Aber meine Programme bekommt keiner umsonst, hat schließlich eine Menge Arbeit gemacht.

Bitte prüfe doch einmal ob Dein Progrämmchen wirklich so toll ist wie Du meinst. Leicht hat man sich einfach nur überschätzt.

Nette Grüße
Robert

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!