*.EXE Starten

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?

Hallo,

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

vlad_tepesch

wenn du eine Konsole haben willst, kannst du natürlich auch das Programm "Start" oder "cmd" mit entsprechenden Parametern aufrufen (per shellexecute versteht sich)

Code-Walker

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

Code-Walker schrieb:

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".

Code-Walker

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

Code-Walker schrieb:

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

vlad_tepesch

shellexecute öffnet kein konsolenfenster, außer die gestartete Anwendung ist eine Konsolenanwendung.
Wenn du das Fenster nicht sehen möchtest, versuchs mal mit SW_HIDE (weiß aber nicht, ob das auf das so erzeugte Konsolenfenster einen Einfluss hat)