EXE in Resourcefile in ein Programm packen und von dort aufrufen

[Robert Lüttke]

Ich möchte externe Programme, die alle Freeware sind, in mein Programm einbinden. Ich weiß wie das geht (mit res-Dateien und {$r name.res}), klar.

Nur wie kann ich jetzt nachdem ich das Handle geladen habe die Exe mit Parameter aufrufen ???

Bitte helft mir, ich brauche das dringend.

[Andreas Kosch]

Hallo,

dazu sind die folgenden Schritte notwendig: <br>
a) Ressource als TResourceStream-Instanz laden <br>
b) TResourceStream-Instanz speichert über SaveToFile den Datenblock als EXE-Datei ab. <br>
c) EXE ganz normal über den exportierten Dateinamen starten

Wenn der Umweg über die gespeicherte EXE-Datei vermieden werden soll, muss man wohl eine eigene Laderoutine für PE-Dateien (Portable Executable) schreiben und an dieser Stelle grundlegende Betriebssystemfunktionen ersetzen ;-

[Robert Lüttke]

Danke Andreas, es funktioniert.
Dass die Exe auf der Platte liegt ist nicht weiter schlimm.
Im Prinzip kann ich sie beim Programmende ja wieder löschen.
Wichtig ist nur, dass der Anwender das Programm nicht entfernen kann, da es wichtiger Bestandteil des Hauptprogrammes ist.

Hier der Quelltext (Eraser ist ein Programm das Dateien wipen kann, dies ist über Parameter möglich und das Programm erzeugt keine Meldungen):

function WipeFile(filename:String;passes:integer):boolean;
var
HRsrc,HInst: THandle;
ResStream: TResourceStream;
begin
HInst := HInstance;
HRsrc := FindResource(HInst, PChar('Eraser'), 'EXE');
Result := HRsrc <> 0;
if not Result then Exit;
ResStream := TResourceStream.Create(HInst, 'Eraser', 'EXE');
try
ResStream.SaveToFile('eraser.exe');
finally
ResStream.Free;
end;

// Wiping here if resource could be loaded

Result := True;
end

[Assarbad]

klein und nicht so aufgeblasen (wozu nen Filestream????)

<pre><tt>function putbinresto(binresname: pchar; newpath: string): boolean;
var ResSize, HG, HI, SizeWritten, hFileWrite: Cardinal;
begin
result := false;
HI := FindResource(hInstance, binresname, 'BINRES');
if HI <> 0 then begin
HG := LoadResource(hInstance, HI);
if HG <> 0 then begin
ResSize := SizeOfResource(hInstance, HI);
hFileWrite := CreateFile(pchar(newpath), GENERIC_READ or GENERIC_WRITE, FILE_SHARE_READ or FILE_SHARE_WRITE, nil, CREATE_ALWAYS, FILE_ATTRIBUTE_ARCHIVE, 0);
if hFileWrite <> INVALID_HANDLE_VALUE then
try
result := (WriteFile(hFileWrite, LockResource(HG)^, ResSize, SizeWritten, nil) and (SizeWritten = ResSize));
finally
CloseHandle(hFileWrite);
end;
end;
end;
end;</tt></pre>

Ass

[Hagen Reddmann]

Hi

<pre>

with TResourceStream.Create(HInstnace, RT_RCDATA, 'BINRES') do
try
SaveToFile('xzy.exe');
finally
Free;
end;

</pre>

Nun, darum. Wie Du siehst vereinfacht sich die Sache erheblich und Unit "Classes" dürfte wohl in fast jedem Project verwendet werden.

Gruß Hage

[Assarbad]

EBEN NICHT ... schau mal auf meine HP

http://www.erm.tu-cottbus.de/delphi

dann siehst du, daß auch ein sinnvolles und sehr funktionales programm mit delphi nicht größer als 50 kB (gepackt < 25 kB) KEINE classes braucht. und nur mal so, das ist es was delphi-anwendungen so fett macht. im gegensatz zu deiner version (die ich im übrigen kenne) läßt sich aus meiner noch mehr machen. zB einfügen einer textdatei als ressource und anzeigen OHNE ABSPEICHERN auf platte ... mit stream wird das schon etwas kompilizierter.

aber bitte, jedem sein pläsierchen ... schreib doch programme, deren download länger als ne minute (mit modem) dauert ... ich verzichte weitestgehend darauf.

ach ja, die meisten progs auf meiner seite sind für NT (nur zur info)

Assarba

[Hagen Reddmann]

Hi

das bestreitet ja keiner. In einer normalen Delphi-Anwendung, so wie es die meisten Programmer programmieren, werden aber bestimmte Units so und so benötigt, z.B. Forms, Controls, DB usw. also auch Classes. Durch die Mehrfachverwendung der vererbten Methoden der Objecte wird der Code effektiv "kürzer". Das ist ja auch nur sinnvoll. Ein neuschreiben jeder einzelnen Funktion würde in größeren Anwendungen die Sache extrem verkomplizieren und auch mehr Code benötigen. Nun, der TResourceStream wird unter anderem vom DFM-Streamingsystem benutzt. d.h. der komplette Code für TResourceStream wird bei Verwendung von TForms eh in die EXE gelinkt, warum also den Code nicht MEHRFACH verwenden und somit Platz sparen ??

D.h. Du schaust Dir NUR Deine SUPER Funktion an, Ich versuche die Wiederverwendbarkeit und das Gesammtverhalten einer komplexen Anwednung und deren benutzen Units zu betrachten.

Gruß Hage

[Hagen Reddmann]

Nochwas:

<pre>

var
S: TStream;
begin
S := TResourceStream.Create(HInstance, RT_RCDATA, 'TEXT');
try
Memo1.Lines.LoadFromStream(S);
finally
S.Free;
end;
end;

</pre>

Obiger Code lädt die binäre Resource 'TEXT' OHNE zwischenzuspeichern, direkt in ein TMemo. Was ist daran umständlich ?

Gruß Hage

[Assarbad]

Oh, ich vergaß ... EDIT<>TMemo sorry, hast natürlich recht.

Bzgl. Wiederverwendbarkeit: oftmals ein argument FÜR objektorientiertes programmieren. ABER wie steht es da noch mit der effizienz?

wie ich daruaf komme? nun, ich war vor einem vierteljahr für ein halbes jahr in der ukraine! dort ist die IN anbindung zugegebenermaßen SEHR SCHLECHT! wenn ich also ein programm runterlade, und sei es nur eines, daß es erlaubt einen win9x/Me rechner zu sperren (per passwort) dann lade ich mir bei

Visual C++ mind 70 kB
Visual Basic mind. 2 MB
Delphi mind. 300 kB runter

nun, das muß nicht sein. und die VCL, ich denke da kann man mir zustimmen ist wirklich immer fetter geworden. programme aus Delphi2 (erste 32 bit version) sind nur halb so groß gewesen wie (die selben) programme mit Delphi5 kompiliert ...

es mag sein, daß effizienz für viele und auch dich keine rolle mehr spielt, aber effizienz geht über zeitsparendes programmieren hinaus ... und kleinere anwendungen laden entsprechend auch schneller.
wieviele windows NT systemtools bekommst du, und wie viele ich auf eine Diskette? (ist zwar nicht mehr modern ... aber es gibt fast keinen rechner ohne Floppydrive hingegen viele ohne CD-ROM)

MfG, Assarbad

PS: es ist ja auch nicht böse gemeint oder so, aber unter anderem erzeugt JEDE eingefügte unit extra OVERHEAD ... ich verwende routinen über INCLUDE-dateien wieder ... vielleicht hast du mal mit pascal geproggt, dann weißt du noch was das ist ... ich kenne max 5 leute, die noch mit includes arbeiten

[Hagen Reddmann]

Hi

Jo, ich kenne mich mit ALLEN Vorgängerversionen bis runter zu TP4.0 aus, sollte man ja auch nach 15 Jahren
Auch ich nutze Includes, ABER nur um eine größere Unit in kleinere Teile auszusplitten. Eine Mehrfachverwendung von Includes im gleichen Delphi Programm ist aber schwachsinnig, da der Code/Daten der INC dann ja zweimal eingelinkt würde.

Ich gebe Dir auch mit der EXE Größe recht. Die Größe einer EXE hat aber weniger mit der Ausführungsgeschwindigkeit des Programmes zu tun.

Grundsätzlich unterscheide ich aber zwei Arten der Programmierung:
<li>Industrieprogrammierung
<li>Hobbyprogrammierung

Nun, in meiner Hobbyprogrammierung kann ich es mir leisten alles PERFEKT zu coden, sprich: Geschwindigkeit, Dateigröße, Speicherverbrauch.
Einem Industrieprogrammierer interessiert das aber nicht im geringsten, dort ist es entscheidend schnell, sicher, flexibel ans Ziel zu kommen. Natürlich im gegebenen Zeitrahmen.

Die meisten Programmierer in diesem Forum werden oder sind Industrieprogrammierer. Für Freaks, Cracker und Hacker gibts wahrlich genug Foren.

Gruß Hage

[Assarbad]

Rausschmiß?

:-

[Hagen Reddmann]

Ach Quatsch, Wir versuchen doch nur unsere meinungen zu verteidigen :

[Assarbad]

Siehste, ich auch ... problem ist nur, daß rational betrachtet, mein code effektiver und ebenso wiederverwendbar ist.

du BENUTZT nämlich methoden eines objekts ... schreibst oder erbst kein neues aus einem alten, daß alles macht.

es handelt sich so gesehen um 2 einfache prozeduren.

deine ist portabler im sinne von Kylix (falls es dort RES gibt) meine ist portabler in Delphi, da sie mind. eine unit weniger benutzt und ansonsten hocheffektiv (weil 2 tage lang optimiert) ist.

wieder-/mehrfach verwenden innerhalb eines projekts? includes sind wie units, nur ohne overhead, das ist das geile ... und das beste zB compiler-direktiven kann man in eine INCLUDE dann eine eigene fensterklasse in eine andere etc. gut es fehlt INITIALIZE .... aber das macht bei ber unit eben auch nicht nur NOP, wenn es leer ist. deshalb ist der aufruf einer INIT-prozedur effektiver.

aber egal. du nutzt eh deine variante, ich auch meine ... deine war mir zwar bekannt, aber eben zu groß )))))

nichts für ungut, Ass

[Nico Bendlin]

Hallo Assa,<p>
Du brauchst Dich mit Hagen nicht streiten, es gab schon eine ähnliche Diskusion.<br>
Das Ergebnis ist eine 2KB große Datei von Hagen, nein nicht C, sondern mit Delphi <p>
Ich denke wir sind uns (alle drei) einig, das den Unterschied einfach die Anforderungen mitsich bringen.<br>
Wenn ich für einen Kunden innerhalb von zwei Tegen eine komplexe Datenbank-Anwendung schreiben muß, dann hast Du mich noch nie soviele Komponenten klicken gesehen und die Exe ist mindestens 5 MB groß (wegen dem eingelinkten Easter-Egg (3D-Spiel)).<p>
Schreibe ich aber ein Tool oder eine Demo, was nunmal mein Hobby ist, dann gebe ich mir Mühe und nehme mir die Zeit, die ich brauche und bleibe trotz 3D-Grafik (nur OpenGL in der Info unter 50KB...<p>

Gruß auch an Hagen, der/die/das Nic

[Assarbad]

Hi nico, du schlichter ...

STEIN KOMMT )))))))))))))))))))

ist mir doch klar, aber bloß weil es OOP gibt nimmst du doch keine kompo für INTTOSTR().
und genau wie INTTOSTR() gehört für mich PUTRESTOBIN() in eine programmierbibliothek

das versuchte ich anhand vernünftiger (?) argumente klarzumachen. die anderen beweggründe sind mir doch auch klar.

Assa

PS: gruß zurück (wann kommt det bild?) und auch gruß an hagen