RCC und executables?
RCC und executables?
Hi,
ist es möglich eine ausführbare Datei als Ressource mit in ein Programm zu kompilieren und in QProcess zu nutzen?
ist es möglich eine ausführbare Datei als Ressource mit in ein Programm zu kompilieren und in QProcess zu nutzen?
Hab ich gemacht aber der Process läuft nicht an, deswegen hat es mich generell mal interessiert. Wäre halt praktisch wenn man kleine execs noch mit einpacken könnte. Entweder geht es nicht (das Ausführen, Einpacken geht schon) oder ich brauch ne spezielle RCC Option. Unter jenen hab ich aber nichts "passendes" gefunden.
denk mal das problem ist, das er das executable unbedingt von nem Datentraeger will. Sind ja auch einige "besondere" attribute gesetzt. Der loader vom BS laed sich dann alles an die richtigen stelle ...
Du muesstest also die datei zuerst auf die platte kopieren in nen temp verzeichniss, einige attribute setzen (ausfuehrbar machen) und dann sollt es gehen.
Direkt ausm speicher nen prog ausfuehren wird ned gehen.
Die frage bleibt, warum braucht man das ?
Willst du code aus dem eigenen binary in nem eigenstaendigen Prozess ausfuehren, macht man klassischerweisse nen fork/createProzess und laesst das child dann in den richtigen ausfuehrungspfad springen.
"externe" programme springt man eigentlich doch nur an, um sicher derer zu bedienen wenn man an deren funktionalitaet ned anders rankommt. System calls sind eigentlich sonst zu unsicher und fehleranfaellig.
Oder man das ding ned selber verwalten will und die verantwortung auf den User / system Admin abzuschieben. Was bei dir ned der Fall sein kann wennst es selber impliziet mit verpackst.
ciao ...
Du muesstest also die datei zuerst auf die platte kopieren in nen temp verzeichniss, einige attribute setzen (ausfuehrbar machen) und dann sollt es gehen.
Direkt ausm speicher nen prog ausfuehren wird ned gehen.
Die frage bleibt, warum braucht man das ?
Willst du code aus dem eigenen binary in nem eigenstaendigen Prozess ausfuehren, macht man klassischerweisse nen fork/createProzess und laesst das child dann in den richtigen ausfuehrungspfad springen.
"externe" programme springt man eigentlich doch nur an, um sicher derer zu bedienen wenn man an deren funktionalitaet ned anders rankommt. System calls sind eigentlich sonst zu unsicher und fehleranfaellig.
Oder man das ding ned selber verwalten will und die verantwortung auf den User / system Admin abzuschieben. Was bei dir ned der Fall sein kann wennst es selber impliziet mit verpackst.
ciao ...
Auf dem ersten Blick klingt das sicher schon verlockend.
Aber wenn man das Szenario etwas gedanklich fortfuehrt ....
z.b wennd er author des anderen Programms neue versionen rausbringt, oder das andere Programm gravierende sicherheitslecks hat ....
oder neue versionen neue features mitbringen und deine user von ausgehen das du das dann auch kanst
... kommst du immer wieder auf paar unangenehme dinge.
Ich nehme an der Autor bzw. Rechteinhaber ist damit einverstanden, das Du sein Programm binaer in dein Programm verwurstest ... bzw steht unter einer Lizenz die das zulaesst !
Manchmal hat man es als Programmierer ned wirklich einfach .. besonders bei dingen wo man denkt das die trivial sind.
Um was fuer ein externes programm handelt es sich eigentlich ? vielleicht gibts die funktionalitaet auch in anderer form (lib/ dll / so) womit man sich als programmierer meist viel einfacher tut ...
Ciao ...
Aber wenn man das Szenario etwas gedanklich fortfuehrt ....
z.b wennd er author des anderen Programms neue versionen rausbringt, oder das andere Programm gravierende sicherheitslecks hat ....
oder neue versionen neue features mitbringen und deine user von ausgehen das du das dann auch kanst
... kommst du immer wieder auf paar unangenehme dinge.
Du siehst das es technisch ned schon trivial ist. Also ist die frage scho, wo du dir die muehe machst. Nen Setup erstellen ist eigentlich mit den heutigen tools gar ned teuer und schwer. Warum sich dann auf der anderen ebene quaelen ? Zumal dir nen setup-programm auf Urheberrechtlicher Ebene mehr Freiheiten bietet.Somit hätte ich es immer parat und müsste net dafür Sorge tragen dass es immer mitkopiert wird.
Ich nehme an der Autor bzw. Rechteinhaber ist damit einverstanden, das Du sein Programm binaer in dein Programm verwurstest ... bzw steht unter einer Lizenz die das zulaesst !
Manchmal hat man es als Programmierer ned wirklich einfach .. besonders bei dingen wo man denkt das die trivial sind.
Um was fuer ein externes programm handelt es sich eigentlich ? vielleicht gibts die funktionalitaet auch in anderer form (lib/ dll / so) womit man sich als programmierer meist viel einfacher tut ...
Ciao ...
Jup, sehe schon, dass es net zu trivial ist, war auch nur so eine Idee 
Ist ein projektinternes Programm, welches ich halt nutzen muss. Die Überlegung mit der dll ist gar net mal so schlecht, mal schauen ob ich da was machen kann.
Kann man eigentlich Konsolenausgaben des eigenen Programms abfangen? Gehört jetzt zwar net ganz hierher, wäre für mich in diesem Zusammenhang aber mal interessant, da der QProcess ja dann wegfallen würde.
Ist ein projektinternes Programm, welches ich halt nutzen muss. Die Überlegung mit der dll ist gar net mal so schlecht, mal schauen ob ich da was machen kann.
Kann man eigentlich Konsolenausgaben des eigenen Programms abfangen? Gehört jetzt zwar net ganz hierher, wäre für mich in diesem Zusammenhang aber mal interessant, da der QProcess ja dann wegfallen würde.
sicher kann man ....
man kann den eingabestrom(stdin) und ausgabestrom(stdout) und fehlerausgabestrom (stderr) so umbiegen, das der aufrufende Prozess die dinger verwaltet.
QProcess macht ua. genau das und nimmt dir damit die arbeit auf niederer ebene ab.
Unter *nix ist sowas eigentlich "Program" , also das pipen, dort uebernimmt nen grossteil der arbeit die shell.
unter windows musst einige dinge mehr einstellen ...
oder QProcess nutzen, das kannst halt direkt als eingabe und ausgabestrom (ist von QIODevide abgeleitet) nutzen ....
wenn du selber urheber des anderen programmes bist, oder den Urheber disziplinarisch
erreichen kannst warum lagerst die funktionen ned in ner lib aus ??? und nutzt die in beiden programmen direkt. Das waer doch der sauberste weg ?
Ups, sehs grad ... des eigenen Programs ? warum erst auf die konsole schreiben, wenn das dann doch wieder verbiegst ???
Also hasst du das problem, das die funktionen des anderen programms "hardcodiert" auf stdin/stdout lesen/schreiben ???
unter unix gabs was, womit man stdin und stdout im eigenen prozess auf nen anderes filehandle umbiegen kann. unter windows gibts sowas sicher auch ...
Ciao ...
man kann den eingabestrom(stdin) und ausgabestrom(stdout) und fehlerausgabestrom (stderr) so umbiegen, das der aufrufende Prozess die dinger verwaltet.
QProcess macht ua. genau das und nimmt dir damit die arbeit auf niederer ebene ab.
Unter *nix ist sowas eigentlich "Program" , also das pipen, dort uebernimmt nen grossteil der arbeit die shell.
unter windows musst einige dinge mehr einstellen ...
oder QProcess nutzen, das kannst halt direkt als eingabe und ausgabestrom (ist von QIODevide abgeleitet) nutzen ....
wenn du selber urheber des anderen programmes bist, oder den Urheber disziplinarisch
Ups, sehs grad ... des eigenen Programs ? warum erst auf die konsole schreiben, wenn das dann doch wieder verbiegst ???
Also hasst du das problem, das die funktionen des anderen programms "hardcodiert" auf stdin/stdout lesen/schreiben ???
unter unix gabs was, womit man stdin und stdout im eigenen prozess auf nen anderes filehandle umbiegen kann. unter windows gibts sowas sicher auch ...
Ciao ...
Das Problem ist, dass es den "Urheber" nicht mehr gibt
Aber ist ne andere Sache. Ich habe die Ausgaben des QProcess schon abgefangen und es läuft alles super. Es ging mir nur drum ob ich das externe Programm mit in der Exe verpacken kann 
Die andere Sache ist, dass ich einen großen Block externer Libs benutze, welche Ihrerseits auch wieder Ausgaben haben. Kompiliere ich jetzt alles mit Subsystem:Windows, dann fällt die Konsole weg und somit ja auch meine Ausgaben, die ich gerne mit in meiner GUI hätte
Die andere Sache ist, dass ich einen großen Block externer Libs benutze, welche Ihrerseits auch wieder Ausgaben haben. Kompiliere ich jetzt alles mit Subsystem:Windows, dann fällt die Konsole weg und somit ja auch meine Ausgaben, die ich gerne mit in meiner GUI hätte