Endlich ist es soweit.
Seit Jahren ist WinExec von MS als obsolet beschrieben. Jetzt funktioniert es tatsächlich nicht mehr.
Ich habe kürzlich einen Rechner installiert mit aktuellen XP-Pro.
Dann wollte ich ein altes Programm von mir starten und bekam ein allgemeine Schutzverletzung. Da das Programm nichts anderes macht, als ein anderes Programm zu starten, war ziemlich schnell klar, woran es lag. Das Programm benutzte immer noch WinExec.
Ich habe schnell auf ShellExecute umgestellt und schon war alles klar.

Also, wer noch alte Programme mit WinExec hat: Bei aktuellem XP-Pro laufen die nicht mehr!

Also bei mir funktioniert WinExec... Hab auch XP Pro (SP2)...

AXMD

Und MSDN gibt als Voraussetzung sogar noch Vista an. Der Fehler dürfte also woanders liegen, zumal nicht einmal MS es fertig bringen würde nach dem Wegfall einer Funktion Schutzverletzungen zu produzieren.

Eine fehlendende, statisch gelinkte API Funktion würde schon beim Kompilieren die Fehlermeldung "Prozedureinstrungspunkt in DLL nicht gefunden" auslösen. Und WinExec wird bestimmt statisch gelinkt. Es wird eher daranliegen, dass WinExec für 16-Bit Progarmme gedacht ist und etwas intern macht, womit das aufrufende Programm oder aufzurufende Programm nicht klar kommt.

Dann würde ich doch als OS-Entwickler wenigstens eine Art Dummy hinterlassen, um eben so etwas zu verhindern.

Und was soll der Dummy machen? Nichts? Was hätte der Entwickler bzw. der Benutzer davon? Es würde nur große Rätsel aufgeben, warum nichts passiert. Eine meldung ausgeben? Das passiert ja schon, so wohl beim Entwickeln, als auch später beim Benutzer, wenn es auf einem Betriebssystem läuft, auf dem es diese Funktion nicht gibt. Siehe dazu auch diese Funktion, um dem OS vorzugaukeln, dass das Programm als Bildschirmschoner läuft.

Stimmt auch wieder. Nur so etwas absichtlich in einem Programm zu provozieren, würde mich schon etwas schütteln, dass muss doch sanfter gehen.

Gerade gefunden: blogs.msdn.com/oldne...05/10/26/485133.aspx

Gleiches Problem nur mit Icons und Animationen in System DLLs.

Auf allen Rechnern die schon länger XP-Pro haben (immer aktuelle Updates und Patches enthalten), funbktionert es auch. Nur bei wirklich neu installierten nicht mehr.
Da es sich im Firmen-PCs handelt, ist die Konfiguration ansonsten natürlich die selbe. Außer dem OS gibts kein Unterschied.

Wie gesagt, es muss an etwas anderem liegen, da eine fehlende API Funktion obige Fehlermeldung auslöst.

Beim Compilieren bekomme ich keine Fehlermeldung. Allerdings läuft es bei dem PC, auf dem compiliert wird auch. Wenn natürlich mit den neueren Builds von XP-Pro die API-Funktion fehlt, kommt der Fehler logischerweise erst zur Laufzeit.
Womit meine Behauptung, dass WinExec mit aktuellem XP-Pro nicht mehr funktioniert, trotzdem stimmen würde.

jasocul hat folgendes geschrieben:

Womit meine Behauptung, dass WinExec mit aktuellem XP-Pro nicht mehr funktioniert, trotzdem stimmen würde.

Nein, wie Ydobon richtig schreibt:

Zitat:

zumal nicht einmal MS es fertig bringen würde nach dem Wegfall einer Funktion Schutzverletzungen zu produzieren.

Die Fehlermeldung wäre eine andere (Prozedureinsprungpunkt WinExec in bla.dll nicht gefunden)

AXMD

Dann frage ich mich aber ernsthaft, woran das liegen kann. In dem Programm habe ich wirklich nur WinExec durch ShellExecute ausgetauscht (und die ShellAPI-Unit eingebunden). Danach lief alles fehlerfrei.
Oder muss ich langsam an meinem Verstand zweifeln?

Kompilier das www.delphi-forum.de/...t=prozess+verstecken mal auf eine Win9x Rechner, führe es unter Windows XP aus und guck, was passiert.

Ich habe seit ein paar Jahren keinen Win9x-Rechner mehr. Wird also schwierig. Ich weiß aber, worauf du hinaus willst. Die eingebundene DLL-Funktion ist ebenfalls von einem XP-Pro-Rechner. Allerdings ein ältere Version mit allen Updates.
Wenn ich nächste Woche die Zeit dazu finde, werde ich eine Test-Applikation basteln. Vielleicht lässt sich dann die Ursache ermitteln.