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

Funktioniert, dankeschön

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

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!

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.

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

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').

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.

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.

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)

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?

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.

shellexec schrieb:

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

Das ist einer der Gründe, warum man auf system gerne verzichtet, es wird kein Kommandozeilen-Interpreter benötigt, um Programme zu starten.

MfG,

Probe-Nutzer

Also CreateProcess währe nun die beste Wahl? Hmm, ich werd mich mal schlau machen!

Das kommt darauf an, meist ist man mit den Shell*-Funktionen besser dran, da sie einem häufig benötigte Sachen bereits vorgefertigt liefern.
Die Kern-Funktionen der WinAPI erledigen meist nur das Nötigste und man müsste selber zusätzlichen Code schreiben, beispielsweise wenn du eine HTML-Seite mit dem Standardbrowser öffnen willst.
Das ist kein Problem mit CreateProcess, aber ShellExecute nimmt dir die ganze Arbeit ab.

Warum diskutiert ihr überhaupt mit berniesbutt, jemand der solche Kommentare von sich gibt sollte einfach ignoriert werden und man sollte nicht mit ihm "diskutieren".

Ja, aber ShellExecute öffnet im Hintergrund noch eine Konsolenanwendung, was ich sehr unschön finde ... Für meinen Anwendungszweck möchte ich lediglich eine Exe starten die auch von mir geschrieben ist. Das ist eine kleine Exe, die inhalt aus einer config datei ausgiebt, mehr macht die nicht ...

Nein, das tut ShellExecute ganz sicher nicht. Du verwechselst das gerade mit std::system().