4. *.EXE Starten

*.EXE Starten

  • Mod

    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?

    0
  • ?

    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.

    0
  • ?

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

    0
  • ?

    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

    0
  • V

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

    0
  • C

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

    0
  • ?

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

    0
  • C

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

    0
  • ?

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

    0
  • V

    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)

    0
  • ?

    Also ich benutze die Funktion, die für die Sache am praktibalsten ist. Was für einen Sinn macht es mit Kanonen auf Spatzen zu schießen! Und in diesem Falle ist das meiner Meinung nach Ψιπεχεςυτε

    Aber lassen wir den armen Threadersteller nun in Ruhe, das Problem ist ja gelöst!

    0
Anmelden zum Antworten