ShellExecute liefert ERROR_ACCESS_DENIED

[himitsu]

Zitat von MSDN - WinExec:

Note This function is provided only for compatibility with 16-bit Windows. Applications should use the CreateProcess function.

Und ich könnte wetten, dass der Compiler hier ein paar Meldungen anzeigt, die jemand vergessen hat zu beheben.
> mindesten "Auf 'ExecuteCommandLine' zugewiesener Wert wird niemals benutzt"
> und seit Delphi 2009 wird es in ExecuteConsole bestimmt Meldungen bezüglich Unicode geben

[Fukiszo]

Falls etwas mit meinem code nicht stimmen sollte, ich bin offen für Kritik
Ich nutz leider keine IDE um mir solche Meldungen anzuschauen,
ich programmier meist mit Notepad++, reicht aus für meine kleinen belange hehe
Ich hab den source mit/für Delphi 7 erschaffen, wie andere Delphi varianten reagieren weiss ich nicht und kann ich auch nicht testen, tut mir leid.
Für delphi 7 taugt der code, hat mich noch nie im stich gelassen.
WinExec ist rückwärtskompatibel, ja. Ich verstehe das zitat nicht.
Es sind ja mehrere varianten vorhanden, man kann entscheiden wie was ausgeführt wird.
Falls ich ein totes überbleibsel aus test zeiten vergessen hab zu löschen, verzeih #zwei

[himitsu]

Bis auf das Unicodeproblem, was aber zufällig keinen Bufferoverflow erzeugt, sondern eher einen Bufferunderflow, sah ich eine direkten "schwerwiegenden" Fehler.
OK, abgesehn von einer Funktion (WinExex), welche seit 23 Jahren als "nicht verwenden, nur für Abwärtskompatibilität von uraltem Code" gekennzeichnet ist.

In ExecuteConsole wird ab D2009 halt ANSI in einem Unicode-CharArray gespeichert wird, was so kaum stört, aber OemToChar wird meckern, vonwegen potentiellem Datenverlust, weil es ja einen PAnsiChar haben will, aber einen PChar/PWideChar bekommt. (der Compiler weiß nunmal nicht, dass dort wirklich nur ANSI drin ist, durch den vorherigen Fehler beim Befüllen).

Zitat:

Für delphi 7 taugt der code, hat mich noch nie im stich gelassen.

Problem ist halt, dass schon seit 9 Jahren Delphi standardmäßig mit Unicode arbeitet, was in der EDV gefühlt einem halben Jahrhundert entspricht.
Vorallem Codes, welche Andere verwenden sollen, wären gut beraten, wenn sie mit halbwegs aktuellen Delphiversionen zusammen arbeiten.
Tipp zum Testen: https://www.embarcadero.com/de/products/delphi/starter


PS: Wäre vor Jahrzehnten schon AnsiChar statt Char dort verwendet worden, wo explizit ANSI genutzt wird, dann hätte es dieses Problem nicht gegeben.
Sowas war eines der größten Gründe, welche bei Einführung von Delphi 2009 in vielen AltCodes zu Problemen führte.
> immer die "richtigen" Typen verwenden und schon minimieren sich die potentiellen Fehlerstellen.

[Fukiszo]

UniCode, guter Rat kommt schnell, vielen Dank, das lässt sich ja problemlos justieren/nachrüsten,
zum beispiel mit einer "if compiler version >= XYZ" then pAnsiChar anstelle pChar direktive.

Danke für den Link, auf arbeit kann ich mit RADStudio XE 10.2 compilieren, ich sollt mal meine privaten codes damit checken,
danke nochmals für den Hinweis.

Für meine privaten Zwecke erstellt mir Delphi ab Version über 7 viel zu grosse Dateien (dateigröße),
deshalb bleib ich privat bei 7 und programmiere privat auch nur damit.

WinExec:
Nur weil was nicht benutzt werden sollte, sollte doch zumindest die möglichkeit gezeigt werden das solch eine funktion existiert
bzw. wie man diese veraltete funktion in der jetzt-zeit dennoch erfolgreich einsetzen könnte, oder etwa nicht?
Delphi 7 hat halt die definition in der Windows.pas datei, ich zeig wie man sie einsetzten könnte.

Danke für deine draufsicht ob fehler existieren!!!

[HolgerX]

Hmm..

Da bei Delphi 7 PChar = PAnsiChar ist, kannst Du auch eigendlich konsequent immer PAnsiChar verwenden.
Jedoch dann am Besten auch ShellExecuteA und die Strings sollte dann fix AnsiString sein.

Alternativ konsequent PWideChar in Verbindung mit ShellExecuteW und WideString.

Dann ist es Type-Konform, egal welche Delphi Version.

[himitsu]

Eine nutzbare Funktion mit abgelaufenem Code neu zu verbreiten ist nicht wirklich ideal.
Am Ende kommt noch wer auf die Idee und baut es in ein neues Programm ein.


Wie gesagt, an der Stelle ist garkein IFDEF nötig.

ReadFile liefert OEM, also ANSI,
OemToChar will ANSI rein bekommen,
also braucht der Buffer immer nur ANSI zu sein und wird somit auch explizit als ANSI deklariert. (AnsiChar/PAnsiChar/AnsiString)



Da gibt es bei deinem Trainer schlimmere Problemstellen, wenn man mit Unicode kompilieren würde (ab Delphi 2009)
und Einiges (FixStr) ist in jeder Delphiversion potentiell gefährlich.

Hier Function StatusText ( StatusID : myStatusIDs ) : pChar; stdcall; klappt das mit dem Result, da es auf Konstanten zeigt, die bestehen bleiben.

Bei Function FixStr ( Input : PChar ) : PChar; stdcall; zeigt Result auf eine temporäre Variable, die beim Verlassen der Funktion freigegeben wird.
Wird der Speicher zwischenzeitlich mit irgendwas überschrieben, dann knallt es womöglich.
War die Variable der letzte genutzte Teil des Speicherblocks, dann wird der freigegeben und es knallt.
Mit etwas Glück passiert nichts und es wird anschließend auf den noch nicht freigegebenen/überschriebenen Speicherbereich zugegriffen.

MessageBox(Handle, PAnsiChar(... : Wie schon gesagt, muß alles zusammenpassen.
String > PChar > MessageBox
AnsiString > PAnsiChar > MessageBoxA
WideString/UnicodeString > PWideChar > MessageBoxW

Mein Tipp wäre hier einfach immer nur mit String/AnsiString/WideString/... zu arbeiten, vorallem bezütlich String-Verarbeitung und Speichermanagement (speichern und weitergeben der Strings)
und nur bei übergabe an die WinAPI nach PChar zu casten.

[Fukiszo]

beim debuggen der shellexecute funktion ist mir folgendes aufgefallen,
wenn die datei die man mit shellexecute ausführen will,
die aber "locked" ist, wie zum beispiel "PageFile.sys"
dann gibt es leider auch den ERROR_ACCESS_DENIED.