Programm als bestimmter Nutzer starten

[Moombas]

Moin zusammen,

ich starte ein externes Programm per CreateProcessWithLogonW. Gibt es hier die Möglichkeit, den "Arbeitspfad" (wie beim shellexecute auch möglich) des externen Programms fest zu legen? Ich konnte dazu aktuell leider nicht viel finden, das externe Programm muss jedoch zwingend in seinem Ursprungspfad ausgeführt werden.

Evtl. bin ich auch einfach blind.

Edit: Fehler gefunden... -.-

[Luckie]

Und was war jetzt die Lösung? :roll:

[himitsu]

Er war blind. :zwinker:

lpCurrentDirectory siehe CreateProcessWithLogonW

[KodeZwerg]

Ich sollte meinen Code auch mal überarbeiten, mehr als alt und ausgedient.

Delphi-Quellcode:

function RunAs(const Handle: Hwnd; const Path, Params: string): Boolean;
var
  sei: TShellExecuteInfoA;
begin
  FillChar(sei, SizeOf(sei), 0);
  sei.cbSize := SizeOf(sei);
  sei.Wnd := Handle;
  sei.fMask := SEE_MASK_FLAG_DDEWAIT or SEE_MASK_FLAG_NO_UI;
  sei.lpVerb := 'runas';
  sei.lpFile := PAnsiChar(Path);
  sei.lpParameters := PAnsiChar(Params);
  sei.nShow := SW_SHOWNORMAL;
  Result := ShellExecuteExA(@sei);
end;

[himitsu]

Sowas von alt ... stimmt.

Nichtmal in deinem Delphi 2010 wird er funktionieren, da die grundlegensten Dinge falsch sind,
was übrigens auch der Hauptgrund ist, weswegen viele Codes seit dem Jahre 2009 plötzlich abrauchen.

Aber keine Sorge, denn der Compiler wird das Problem freundlich mit Warnungen beglücken, (nur blöd, dass zu viele alle Warnungen einfach ignorieren)
denn du gibst einen "veränderlichen" compilerabhängigen Typen in einen statischen Cast und Funktionsaufruf rein
und im Jahre des Delphi 2009 änderte sich dieser Typ, weswegen es nun knallt.

String -> PChar -> WinApi
AnsiString -> PAnsiChar -> WinApiA
WideString/UnicodeString -> PWideChar -> WinApiW

[KodeZwerg]

Delphi-Quellcode:

function RunAs(const Handle: Hwnd; const Path, Params: string): Boolean;
var
  {$ifdef UNICODE}
    sei: TShellExecuteInfoW;
   {$else UNICODE}
    sei: TShellExecuteInfoA;
  {$endif UNICODE}
begin
  FillChar(sei, SizeOf(sei), 0);
  sei.cbSize := SizeOf(sei);
  sei.Wnd := Handle;
  sei.fMask := SEE_MASK_FLAG_DDEWAIT or SEE_MASK_FLAG_NO_UI;
  sei.lpVerb := 'runas';
  sei.nShow := SW_SHOWNORMAL;
  {$ifdef UNICODE}
    sei.lpFile := PWideChar(WideString(Path));
    sei.lpParameters := PWideChar(WideString(Params));
    Result := ShellExecuteExW(@sei);
   {$else UNICODE}
    sei.lpFile := PAnsiChar(AnsiString(Path));
    sei.lpParameters := PAnsiChar(AnsiString(Params));
    Result := ShellExecuteExA(@sei);
  {$endif UNICODE}
end;

Danke himitsu, nun gibt es keine Warnungen und es macht noch das selbe, es führt ein programm im admin-modus aus.

[Dalai]

@KodeZwerg: Nein, immer noch falsch. PChar gehört da hin, wenn du TShellExecuteInfo und String statt TShellExecuteInfoW und WideString als Typen benutzt.

Auf einem Delphi mit Unicode macht es keinen Unterschied, aber auf einem Delphi ohne kommen mit dem Code wieder (zu Recht) Warnungen. Wenn du PChar verwendest, funktioniert es in allen Delphis, ob Unicode oder nicht.

Grüße
Dalai

[KodeZwerg]

Ja da brauch ich noch Nachhilfe, mal wird einem gesagt nimm die ohne A/W sondern entscheide per PAnsi/PWide welche Version intern aufgerufen wird (mit d2010 wählt der dann W), nun wieder das ich bei A/W bleiben soll.

Wie ists denn nun richtig?

Habe code updated, so nun korrekt?
(nochmal updated, hatte deine widestring hinweis zuerst vergessen)

[himitsu]

Im Prinzip stimmt es sozusagen schon, aber die IFDEFs können weg, wenn man gleich den passenden Typ verwendet.


compilerabhängig:

Delphi-Quellcode:

function RunAs(const Handle: Hwnd; const Path, Params: string): Boolean;  
var
  sei: TShellExecuteInfo;
begin
  FillChar(sei, SizeOf(sei), 0);
  sei.cbSize := SizeOf(sei);
  sei.Wnd := Handle;
  sei.fMask := SEE_MASK_FLAG_DDEWAIT or SEE_MASK_FLAG_NO_UI;
  sei.lpVerb := 'runas';
  sei.nShow := SW_SHOWNORMAL;
  sei.lpFile := PChar(Path);
  sei.lpParameters := PChar(Params);
  Result := ShellExecuteEx(@sei);
end;

String ist ein compilerabhängiger Typ, wie z.B. Integer (früher mal 16 Bit und dann 32 Bit ... allerdings wurde der Integer für 64 Bit-CPUs eingefroren und dafür was Neues erfunden, welches in Delphi sich NativeInt nennt)

fest, immer als ANSI: (das Gleiche bei Unicode, mit Wide/W)

Delphi-Quellcode:

function RunAs(const Handle: Hwnd; const Path, Params: AnsiString): Boolean;
var
  sei: TShellExecuteInfoA;
begin
  FillChar(sei, SizeOf(sei), 0);
  sei.cbSize := SizeOf(sei);
  sei.Wnd := Handle;
  sei.fMask := SEE_MASK_FLAG_DDEWAIT or SEE_MASK_FLAG_NO_UI;
  sei.lpVerb := 'runas';
  sei.nShow := SW_SHOWNORMAL;
  sei.lpFile := PAnsiChar(Path);
  sei.lpParameters := PAnsiChar(Params);
  Result := ShellExecuteExA(@sei);
end;

Windows bietet für fast alle WinAPIs zwei Versionen der Funktionen an (ShellExecuteExA und ShellExecuteExW)
und Delphi stellt schon immer diese APIs auch als compilerabhängige Variante an. (ShellExecuteEx als Alias für ShellExecuteExA oder ShellExecuteExW ... vor D2009 und ab D2009)

[KodeZwerg]

@himitsu, ich habe leider gerade nichts zum testen aber noch eine Frage zu dem Unicode, würde bei PChar da nicht Unicode kaputt gehen?
Mein Beispiel betreffend, code wird in russland oder china ausgeführt, würden da dann nicht die multibyte chars zu single byte und das resultat wäre nicht das was man eigentlich wollte?

[Schokohase]

Warum sollte da etwas kaputt gehen?

Unicode-Delphi (alles ab Delphi 2009):

Delphi-Quellcode:

string

ist ein Alias für

Delphi-Quellcode:

UnicodeString

.

Delphi-Quellcode:

PChar

ist ein Alias für

Delphi-Quellcode:

PWideChar

.

ANSI-Delphi (alles vor Delphi 2009):

Delphi-Quellcode:

string

ist ein Alias für

Delphi-Quellcode:

AnsiString

.

Delphi-Quellcode:

PChar

ist ein Alias für

Delphi-Quellcode:

PAnsiChar

.

[KodeZwerg]

Danke Euch Drei, nun ists angekommen. Super Erklärung, das hilft sehr!:thumb:

[himitsu]

Zitat:

Zitat von himitsu (Beitrag 1414741)

String -> PChar -> WinApi
AnsiString -> PAnsiChar -> WinApiA
WideString/UnicodeString -> PWideChar -> WinApiW

Darum auch immer nur das Passende zusammen verwenden.
Ansonsten muß der String ANSI-Unicode entsprechend gecastet werden.

Beispiel:
String (AnsiString) mit PAnsiChar ging in Delphi vor 2009,
aber aber 2009 passt String (UnicodeString) und PAnsiChar nicht mehr.

Hätte man früher aber die "richtigen" Typen zusammen verwendet, dann würde es mit Umstellung auf Unicode keine Probleme geben.

[Moombas]

Ich war blind = Ich habe die Übergabe des Arbeitsverzeichnisses an die falsche Stelle übergeben -.-

[Moombas]

Eine kleine Ergänzung:

Bekomme ich aus der Funktion irgendwie folgende Informationen:

TStartupInfo
TProcessInformation

Delphi-Quellcode:

//Prozess als bestimmten Benutzer starten (Hilfsaufruf)
procedure TTools.startasSU(exe, param : string);
var
  User              : WideString;
  PW                : WideString;
  err               : DWORD;
begin
  User := 'yyy';
  PW   := 'xxx';
  err  := CreateProcessAsLogon(User, PW, exe, param, '');
  if err <> 0 then
    ShowMessage(SysErrorMessage(err));
    CreateProcess(
end;

Ich möchte das gestartete Programm an anderer Stelle ggf. beenden, daher bräuchte ich die Informationen, außer ihr habt eine bessere Idee.

Aktuell würde ich dies über folgende Lösung machen:

Starten:

Delphi-Quellcode:

var
  SI: TStartupInfo;
  PI: TProcessInformation;
begin

  FillChar(SI, SizeOf(TStartupInfo), 0);
  SI.cb := SizeOf(TStartupInfo);
  if CreateProcess(nil, 'NOTEPAD.EXE', nil, nil, False, 0, nil, nil, SI, PI) then
  begin
    AppPID := PI.dwProcessId;
    CloseHandle(PI.hProcess);
    CloseHandle(PI.hThread);
  end;

Beenden:

Delphi-Quellcode:

  function EnumWindowsProc(hWnd: HWND; lParam: LPARAM): BOOL; stdcall;
  begin
    TList(lParam).Add(Pointer(hWnd));
    Result := True;
  end;

  procedure Wait(MilliSeconds: DWORD);
  var
    Stop: DWORD;
  begin
    Stop := GetTickCount + MilliSeconds;
    while Stop > GetTickCount do
    begin
      Sleep(100);
      Application.ProcessMessages;
    end;
  end;

var
  List: TList;
  I: Integer;
  ProcessId: DWORD;
  ThreadId: DWORD;
  ProcessHandle: THandle;
  ExitCode: DWORD;
begin

  if AppPID <> 0 then
  begin
    List := TList.Create;
    try
      EnumWindows(@EnumWindowsProc, LPARAM(List));
      for I := 0 to List.Count - 1 do
      begin
        ThreadId := GetWindowThreadProcessId(HWND(List.Items[I]), ProcessId);
        if ProcessId = AppPID then
        begin
          SendMessageTimeout(HWND(List.Items[I]), WM_SYSCOMMAND, SC_CLOSE, 0, SMTO_ABORTIFHUNG, 500, DWORD(nil^));
          Wait(3000);
          if IsWindow(HWND(List.Items[I])) then
          begin
            PostThreadMessage(ThreadId, WM_QUIT, 0, 0);
            Wait(3000);
            ProcessHandle := OpenProcess(PROCESS_ALL_ACCESS, False, ProcessId);
            if ProcessHandle <> 0 then
            begin
              GetExitCodeProcess(ProcessHandle, ExitCode);
              TerminateProcess(ProcessHandle, ExitCode);
              CloseHandle(ProcessHandle);
            end;
          end;
          Break;
        end;
      end;
    finally
      List.Free;
    end;
  end;

Code von Sprint

[DieDolly]

Ich antworte nicht auf dein Problem aber auf etwas anderes.

Zitat:

procedure TTools.startasSU(exe, param : string);

Mich würde zu sehr interessieren, wie du TTools implementiert hast. Ich sehe, dass du die Starter verwendest. Du arbeitest also vermutlich nicht in einer großen Firma oder so.
Wenn TTools bei dir eine Klasse ist von der du eine Instanz erstellen musst empfehle ich dir, das zu einem Record umzuschreiben. Etwa so

Delphi-Quellcode:

type
 TTools = record
 public
  class procedure startasSU(exe, param : string); static;
 end;

implementation

class procedure TTools.startasSU(exe, param : string);
begin

end;

Aufruf dann überall über

Delphi-Quellcode:

TTools.startasSU()

.

[Schokohase]

@DieDolly

Warum zwanghaft ein Record?

Eine Klasse kann auch eine

Delphi-Quellcode:

class procedure

haben und der Aufruf ist gleich.

Es gibt allerdings einen Vorteil: Man kann eine Klasse vererben und dadurch eben erweitern. Bei einem Record geht das nicht.

[HolgerX]

Hmm..

[OT]

Zitat:

Zitat von DieDolly (Beitrag 1420311)

Delphi-Quellcode:

type
 TTools = record
 public
  class procedure startasSU(exe, param : string); static;
 end;

implementation

class procedure TTools.startasSU(exe, param : string);
begin

end;

Wieso nen Record ?

Delphi-Quellcode:

//oder
 TTools = class
 public
  class procedure startasSU(exe, param : string); static;
 end;

Ne class geht doch auch ;)

[OT]

(Mist zu langsam.... ;) )

[Moombas]

Delphi-Quellcode:

type
  TTools = class(TForm)

Ggf. hätte ich es einfach wie HolgerX/Schokohase aufrufen können. Nun aber bitte BTT ;)

[DieDolly]

Zitat:

Ne class geht doch auch

Muss man dann nicht eine Instanz davon erstellen? Mit einem Record fällt das jedenfalls weg.

[Luckie]

Nicht bei einer Klassen Procedure.

[DieDolly]

Zitat:

Wieso nen Record ?

Dann mein letztes Argument Pro-Record: weniger Müll in der Codevervollständigung :stupid:

[Dennis07]

Als Admin kannst du auch über ShellExecute starten, mit der Aktion

Delphi-Quellcode:

'runas'

[Moombas]

-.- also kann man nun bitte zu meiner Frage zurückkehren anstatt hier mit OT alles vollzumüllen? Danke.

Najaj etwas gutes hatte es, habe gesehen das ich in einem darauf bezogenen Prozess die Information bereits erhalte und kann damit arbeiten. Daher Frage erledigt.