*.EXE Starten

Code-Walker

Ich möchte gerne aus meinem Programm heraus eine andere Exe starten. So, als ob ich doppelklick auf diese exe machen würde. ShellExecute hat mir leider nicht weiter geholfen, ich bekomme es lediglich hin damit den Explora zu öffnen, wo dann der Ordner geöffnet ist, indem sich die exe befindet:

ShellExecute(NULL, "open", NULL, NULL, "Error.exe", NULL);

Ich empfehle hierfür die Windows API Funktion WinExec. Mit dieser Funktion lassen sich beliebige Programme starten und auch ausführen! Die details findet man wie immer in der MSDN (Microsoft Developer Network!)

Code-Walker

WinExec("Error.exe", SW_SHOW);

Funktioniert, dankeschön

vlad_tepesch

warum sollte shellExecute nicht funktionieren?

Der vorteil von ShellExecute ist, dass man als dateiname auch eine beliebige datei angeben kann, zu der ein eAnwendung registriert ist.
Das heißt, wenn man als dateiname eine html-Datei angibt öffnet er diese in dem standardbrowser (normalerweise Firefox ;-P).

WinExec sollte auf jeden fall NICHT verwendet werden.
Grund:
Die gibts nur noch aus kompatibilitätsgründen für 16bit windows-Programme (wer weiß, wie lange noch).

Dein ShellExecute befehl hat falsche parameter, der dateiname ist NULL

HINSTANCE ShellExecute(
    HWND hwnd,	// handle to parent window
    LPCTSTR lpOperation,	// pointer to string that specifies operation to perform
    LPCTSTR lpFile,	// pointer to filename or folder name string
    LPCTSTR lpParameters,	// pointer to string that specifies executable-file parameters 
    LPCTSTR lpDirectory,	// pointer to string that specifies default directory
    INT nShowCmd 	// whether file is shown when opened
   );

ShellExecute(NULL,                        // kein elternfenster
             "open",                      // öffnenbefehl
             "c:\\Windows\\Notepad.exe",  // notepad.ese starten
             "c:\\boot.ini",              // mit boot.ini als Datei zum anzeigen
             ".",                         // ausführungsverzeichnis das aktuelle
             SW_MAXIMIZE);                // Programm maximiert starten

Von ShellExecute rate ich ab, weil durch die vielen Parameter nur mehr Möglichkeiten bestehen Fehler einzubauen. Außerdem arbeitet ShellExecute manchmal unzuverlässig, wenn es um COM Dateien geht!

Code-Walker

Verstehe ich das jetzt richtig? Diese funktion geht nur in 16Bit versionen von windows? bei mir geht sie und ich habe eine 32 bit version ...

Mal eine andere frage, will deswegen nicht extra ein neues Thema aufmachen:

wsprintf(szPath, "%s\Error.ini", szFileName);

Das problem ist, das der '/' nicht mit geht, und leider soll dieser Querstrich dort aber sein! Wie kriege ich das nun hin das der Querstrich nicht als solch ein umbruchs element angesehen wird?

EDIT::::::::::::::::

Muss zwei '//' benutzen! Probieren geht über studieren xD!

Die WinExec Funktion funktioniert in JEDER Windows Version, SOGAR in einer 16 bit Version. Das ist also ein Vorteil, man kann sie beruhigt benutzen.

Code-Walker schrieb:

Verstehe ich das jetzt richtig? Diese funktion geht nur in 16Bit versionen von windows? bei mir geht sie und ich habe eine 32 bit version ...

Nein sie funktioniert auch auf 32 bit. Ich glaube er meinte, dass diese Funktion auf 32 bit Systemen nur noch existiert, um kompatibel zu 16 bit Programm zu sein.

Code-Walker

Und auf 64bit Vista gehts auch oder? Also auf jeder Windows vesion ab 16bit?

"The WinExec function runs the specified application.

This function is provided for compatibility with earlier versions of Windows. For Win32-based applications, use the CreateProcess function."

berniebutt

@ Code-Walker: Bei mir läuft WinExex sowohl auf 16bit als auch auf 32bit. 64bit habe ich (noch) nicht verfügbar. Der Hinweis "Nur zur Kompatibilität ..." ist irreführend. Alle anderen Möglichkeiten sind aufwendiger.
Zur anderen Frage: Benutze besser die Stream-Klassen von C++. Die sind einfach zu handhaben. Hier kriegst Du keinen Konflikt mit den Formatierungszeichen, wenn diese Text sein sollen.

_matze

Code-Walker schrieb:

Verstehe ich das jetzt richtig? Diese funktion geht nur in 16Bit versionen von windows? bei mir geht sie und ich habe eine 32 bit version ...

Mal eine andere frage, will deswegen nicht extra ein neues Thema aufmachen:
wsprintf(szPath, "%s\Error.ini", szFileName);
Das problem ist, das der '/' nicht mit geht, und leider soll dieser Querstrich dort aber sein! Wie kriege ich das nun hin das der Querstrich nicht als solch ein umbruchs element angesehen wird?

EDIT::::::::::::::::

Muss zwei '//' benutzen! Probieren geht über studieren xD!

Du meinst '\', nicht "//". Einen Slash kannst du ganz normal notieren (manche WinAPI-Funktionen kommen aber glaube ich nicht damit klar). Einen Backslash musst du dann doppelt notieren, da ein Backslash immer eine Escapesequenz einleitet (das ist das Stichwort, das du nun in Google eingeben solltest ). Ein Beispiel, das du vermutlich kennst, ist das Newline ('\n').

vlad_tepesch

Ich bleib dabei.
Win3.1 Api calls haben in einem modernen Programm nix zu suchen.
Die winAip schleppt diese Altlasten schon viel zu lang mit sich herum (>12 Jahre).
Ein Grund ist dafür sicherlich, dass viele Programmierer aus unwissenheit diese immer noch verwenden. Kann das mal jemand in Vista probieren? Würd mich mal interessieren.

MS hat den Hinweis

This function is provided for compatibility with earlier versions of Windows. For Win32-based applications, use the CreateProcess function.

sicherlich nicht aus Spaß in die API dokumentation eingefügt.

WinExec ist nur noch vorhanden um die Kompatibilität zu 16-Bit Programmen unter 32-Bit Windows sicher zu stellen. Vista (64-Bit) unterstützt keine 16-Bit Programme mehr. Es ist anzunehmen, dass WinExec fort nicht mehr existiert.

Und die Begründung, dass man wegen der höheren Anzahl von Parameter mehr Fehler einbauen kann, ist wohl ganz schwach. Wer so was sagt, hat wohl seinen Job als Programmierer verfehlt.

berniebutt

@ vlad-tepesch: WinExec läuft auch unter Vista32 einwandfrei - sowohl beim Compilieren wie auch in der Ausführung. Vista64 weiss ich nicht.

Es wurde noch nie eine "veraltete" Funktion aus der WinAPI wirklich entfernt und das wird auch zukünftig nicht der Fall sein, da es keinen Sinn macht und Jeder, der Microsoft ein wenig kennt, weiß, wieviel Wert man bei Microsoft auf Abwärtskompatibilität legt. Das geht sogar soweit, daß man Patches für einzelne Anwendungen von Drittherstellern für das Betriebssystem entwickelt. Also wenn man alle Argumente abwägt, kann man ruhigen Gewissens zu WinExec greifen und es ist in diesem Fall die beste Option!

vlad_tepesch

wiso soll es die beste option sein?
Was für ein ausführungsverzeichnis wird denn für die Exe benutzt?
das des eigenen Programms, der Speicherort der Exe?

In Win32, the WinExec function returns when the started process calls the GetMessage function or a time-out limit is reached. To avoid waiting for the time out delay, call the GetMessage function as soon as possible in any process started by a call to WinExec.

Das heißt, wenn die aufgerufene Anwendung kein GetMEssage macht (Konsolenanwenudng), dann friert dein Programm solange ein, bis der Timeout passiert (keine ahnung wie lang er ist)

Martin Richter

vlad_tepesch schrieb:

Das heißt, wenn die aufgerufene Anwendung kein GetMEssage macht (Konsolenanwenudng), dann friert dein Programm solange ein, bis der Timeout passiert (keine ahnung wie lang er ist)

Nein! Tut es nicht. Auch eine Konsolenanwendung wir dkorrekt gestartet und WinExec friert nicht ein.

@berniesbutt: Nur mal so am Rande welche Gefahr in Deinen "falschen" Vermutungen stecken.
Da vermutlich in Zukunft alle Programme ein Manifest bekommen werden, wird es dem Lader wohl auch freistehen, Dein Programm nicht zu laden, weil WinExec deprecated ist. Denn in Deinem Manifest sagtst Du ja: "Mein Programm ist für Windows X", aber für Windows X ist WinExec eben deprecated. Defakto ist WinExec schon seit Win32 deprecated, also nimm es nicht mehr.
Warum glauben so viele Entwickler (inkl. Dir) immer noch Funktionen verwenden zu müssen obwohl MS schreibt: Tut es nicht! Und wenn MS morgen sagt: "WinExec fliegt aus den Link-Libs raus", was dann? Seit Jahren schreiben sie ja: "Bitte nehmt diese Funktion nicht!". Ist dann MS der Bösewicht oder Du nur der Ignorant?
Ich vermute, dass Du Dich dann ganz besonders aufregst, weil Dein Programm nicht mehr kompiliert/gelinkt wird

@berniesbutt: Es ist absoluter Quatsch, dass ShellExecute irgendwo Probleme hat? Und was meinst Du mit COM Dateien? Was sind COM-Dateien? Alle meine Programme verwenden COM.
Es sind schon gar keine Probleme zu erwarten wenn es um das Starten einer BAT oder EXE geht! Warum auch?
Probleme können sicherlich entstehen, wenn man ein "open" für ein ".xyz"-File angibt und die Registry hat falsche einträge für diese Extension!
Und was die Argumente betrifft, die kann man zu 90% auf NULLL stehen lassen. Da macht man keinen Fehler.
Es benutzt im Kern auch irgendwann CreateProcess, genauso wie WinExec...
Dir ist klar, dass der Explorer bei enem Doppelklick auf eine Datei ShellExecute ausführt?

berniesbutt schrieb:

Es wurde noch nie eine "veraltete" Funktion aus der WinAPI wirklich entfernt und das wird auch zukünftig nicht der Fall sein, da es keinen Sinn macht und Jeder, der Microsoft ein wenig kennt, weiß, wieviel Wert man bei Microsoft auf Abwärtskompatibilität legt. Das geht sogar soweit, daß man Patches für einzelne Anwendungen von Drittherstellern für das Betriebssystem entwickelt. Also wenn man alle Argumente abwägt, kann man ruhigen Gewissens zu WinExec greifen und es ist in diesem Fall die beste Option!

Windows Vista 64-Bit unterstützt keine 16-Bit Programme mehr. So viel zur sichergestellten Abwärtskompatibilität. Wenn man alle Argumnte abwägt und man zukunftssicher sein will, dann ist WinExec eben nicht die beste Option.

Mal ne kurze Frage:
ShellExecute() öffnet keine neue Konsole wie es bei system() der Fall ist, oder?