Aufruf von Windows Snipping Tool und Remotehilfe

[Bornholdt]

Hallo,

gelingt mir nicht.

Taschenrechner geht ohne Probleme mit:

procedure Formular.TaschenRechnerClick(Sender: TObject);
begin
inherited;
winexec('Calc.exe',sw_show);
end;

oder eben mit Shellexecute.

Snippingtool.exe - das Windows Screenshot Tool - kann ich nicht aufrufen. Nichts passiert. Genauso würde ich gerne das neue Windows Fernwartungstool aufrufen: Remotehilfe (engl. Quickassist). Sowohl das Snippingtool als auch die Remotehilfe lassen sich von der Eingabeauffordeurng mittels Kommandos "Snippingtool" oder "Quickassist" öffnen analog dem Taschenrechner.
Aus Delphi heraus ebend nicht.

Ideen?
danke

VG

[Fukiszo]

http://www.delphipraxis.net/1390993-post16.html

Da hab ich mehrer Varianten bereitgestellt wie man Dateien ausführen kann,
für Delphi 7 programmiert.

Vielleicht hilft dir das eine oder andere,

Grüße

edit:
ps: man sollte auch angeben wo die datei herkommt (verzeichniss)

[Delphi.Narium]

Zeig' uns bitte mal Deinen vollständigen Quelltext für den Aufruf der beiden Programme per ShellExecute.

[ventiseis]

Also, bei mir funktionierts auch nicht: 64bit Windows 10 1709, SnippingTool.exe liegt unter C:\Windows\System32, eine 32-bit-Delphi-Exe schaut aber unter C:\WINDOWS\SysWOW64 rein, da gibts kein Snippingtool.exe. Entsprechend liefert winexec das Ergebnis 2: File not found.

[Delphi.Narium]

Kann man denn das Programm nicht mit 'ner vollständigen Pfadangabe aufrufen?

Muss man das denn Windows überlassen, welches Programm es konkret aufruft?

[ventiseis]

Eventuell so:

Delphi-Quellcode:

  ShellExecute(Application.Handle, 'open', pchar(ExpandEnvStr('%windir%\sysnative\SnippingTool.exe')), nil, nil, sw_show);

Siehe hier:

• ExpandEnvStr
• Sysnative

[Bornholdt]

beschriebenen Ansätze klappen bei mir nicht!

anbei mein Code:
procedure Formular.SnippingToolClick(Sender: TObject);
begin
inherited;
// winexec('Snippingtool.exe',sw_show);
ShellExecute(Application.Handle, 'open', pchar('c:\windows\system32\SnippingTool.exe'), nil, nil, sw_show);
end;

Quickassist ist eine "neue" WIndows 10 App. Das macht es da noch komplizierter...

[ventiseis]

Hast du das mit dem Sysnative-Pfad auch versucht? Oder verwendest du kein 64bit? Alle Zugriffe auf C:\Windows\System32 von einer 32-bit Anwendung werden bei einem 64-bit Windows auf C:\windows\SysWOW64 umgeleitet, da gibts kein Snippingtool.

Siehe MSDN

[Delphi.Narium]

Bitte den Quelltext mal ändern:

Delphi-Quellcode:

procedure Formular.SnippingToolClick(Sender: TObject);
var
 iError : Integer;
begin
  iError := ShellExecute(Application.Handle, 'open', pchar('c:\windows\system32\SnippingTool.exe'), nil, nil, sw_show);
  if iError < 33 then begin
    ShowMessage(Format('Fehler: %d',[iError]));
  end;
end;

Der Rückgabewert von ShellExecute könnte hilfreich sein ;-)

Fehlermeldungen/Rückgabewerte siehe: https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

[himitsu]

Zitat:

Delphi-Quellcode:

winexec('Calc.exe',sw_show);
end;

oder eben mit Shellexecute.

Nicht "oder eben" sondern "stattdessen".
https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx


Dein Problem ist eben die Verzeichnisumleitung, denn so ist es "schwerer", wenn man wirklich mal auf so ein Verzeichnis zugreifen will.
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

z.B. C:\Windows\System32 ist in einem 64 Bit Windows nunmal für die 64 Bit-Programme, damit es beim Umstieg auf 64 Bit keine Probleme mit hartcodierten Pfaden gibt.
Während Windows bei 32 Bit-Programmen das Verzeichnis standardmäßig auf C:\WINDOWS\SysWOW64 umbiegt.
Meiner Meinung nach hätte man das Umbiegen bei 64 Bit machen sollen, wenn diese Programme "schrottig" programmiert sind, oder besser gleich mit Fehlermeldungen Warnmeldungen reagieren sollen.
Das selbe Problem gibt es mit weiteren Verzeichnissen und auch in der Registry.

[Bornholdt]

Nach Änderung des Quelltexts:

Fehler 2 gibt die Anwendung zurück!

wenns halt net geht, gehts halt net. )

habt ihr mal versucht die quickassist.exe aufrufen?


ich überlege mittlerweile einen umweg über ne bat datei die von der shell aus den befehl ausführt...

[Delphi.Narium]

Fehler 2 heißt:

ERROR_FILE_NOT_FOUND - The specified file was not found.

Entweder das Programm liegt nicht an der angegebenen Stelle oder es fehlen die passenden Zugriffsrechte oder ... siehe oben ...

[Fukiszo]

Eventuell blockiert ein AntiVirus-Programm dein Programm? (Stichwort Virtualisierung)

Das Beispiel von Delphi.Narium ist auf jedenfall korrekt, der Fehler liegt bei Dir.
Existiert denn "c:\windows\system32\SnippingTool.exe" ?
Überprüfe das mit Explorer. (Groß-/Kleinschreibung ist egal, aber Pfad+Name muss stimmen)

Grüße

[EWeiss]

Nein irgendetwas blockiert die Ausführung über Shellexecute.
Und ja "c:\windows\system32\SnippingTool.exe" ? existiert.

Und Schreibweise ist egal ob klein oder groß.
Auch mit meinem Programm OTTB kann ich es nicht starten auch dann nicht wenn ich eine Verknüpfung auf dem Desktop anlege.

Wenn du versuchst diese Datei mit einem Texteditor oder Dependency Walker direkt unter c:\windows\system32 zu öffnen..
ist der Texteditor leer und Dependency Walker gibt diese Meldung aus.

Wohlbemerkt ich habe diese Datei mit rechtsklick und öffnen mit "View Dependencies" gestartet.
bzw.. öffnen mit UEdit. ;)

Das Problem liegt daran das sie als 64Bit unter System32 abgelegt ist und dann beim Aufruf die Datei unter System64 ausführt.
mit diesem Pfad c:\windows\system64\SnippingTool.exe sollte es funktionieren.
Geht zumindest dann mit "Dependency Walker" und meinem Programm OTTB als Verknüpfung auf dem Desktop.
ok wie Dalai sagt gibt es System64 Standard mäßig nicht.

gruss

[Dalai]

Ich gehe mal ganz stark davon aus, dass ihr allesamt Windows 64 bit Systeme verwendet, aber im Delphi nur 32 bit Programme erzeugt. Korrekt? Dann kann es nicht funktionieren, Programme auszuführen, die nur im Verzeichnis %SystemRoot%\system32 liegen. Warum? Weil sämtliche Zugriffe auf dieses Verzeichnis nach %SystemRoot%\SysWOW64 umgeleitet werden dank der File System Redirection. Das wurde ja bereits schon mehrfach erwähnt und verlinkt.

Jedes 32 bit Programm bekommt also eine völlig andere Sicht aufs Dateisystem als 64 bit Programme. SnippingTool.exe gibt's nur einmal auf einem Windows, ganz im Gegensatz z.B. zu cmd.exe, die es zweifach gibt (einmal als 64 bit in \Windows\system32 und einmal als 32 bit in \Windows\SysWOW64).

Lösungsmöglichkeiten:

• Umweg über \Windows\SysNative gehen oder
• Redirection temporär deaktivieren via Wow64DisableWow64FsRedirection und danach wieder zurückstellen mit Wow64RevertWow64FsRedirection.

Eine Batchdatei kann funktionieren, muss aber nicht. Es kommt darauf an, welche CMD gerufen wird beim Ausführen dieser Batch. Sofern das die 32 bit CMD sein sollte, hat man dort das Problem weiterhin.

Grüße
Dalai

[EWeiss]

Zitat:

Weil sämtliche Zugriffe auf dieses Verzeichnis nach %SystemRoot%\SysWOW64 umgeleitet werden dank der File System Redirection.

Nein in dem Fall nicht.

Zitat:

SnippingTool.exe gibt's nur einmal auf einem Windows

Nö 2 mal auch unter System64.

Zitat:

Lösungsmöglichkeiten:•Umweg über \Windows\SysNative gehen oder
•Redirection temporär deaktivieren via MSDN-Library durchsuchenWow64DisableWow64FsRedirection und danach wieder zurückstellen mit MSDN-Library durchsuchenWow64RevertWow64FsRedirection.

bringt gar nichts.
führe diese unter System64 aus und gut ist.

gruss

[Dalai]

Das Verzeichnis \Windows\System64 gibt es standardmäßig nicht. Eine so benannte Junction anzulegen, die auf \Windows\system32 zeigt, ist ein weiterer möglicher Workaround - analog zu dem schon vorhandenen, aber nur für 32 bit Programme sichtbaren \Windows\SysNative.

Wenn man das macht, sind logischerweise alle Dateien in \Windows\system32 mit denen in \Windows\System64 identisch - ist ja dasselbe Verzeichnis. Die Dateien darin gibt es aber nur einmal (und sie haben auch wegen der Junction keinen höheren Hardlink-Count).

Grüße
Dalai

[EWeiss]

Zitat:

Zitat von Dalai (Beitrag 1392606)

Das Verzeichnis \Windows\System64 gibt es standardmäßig nicht. Eine so benannte Junction anzulegen, die auf \Windows\system32 zeigt, ist ein weiterer möglicher Workaround - analog zu dem schon vorhandenen, aber nur für 32 bit Programme sichtbaren \Windows\SysNative.

Wenn man das macht, sind logischerweise alle Dateien in \Windows\system32 mit denen in \Windows\System64 identisch - ist ja dasselbe Verzeichnis. Die Dateien darin gibt es aber nur einmal (und sie haben auch wegen der Junction keinen höheren Hardlink-Count).

Grüße
Dalai

Hmmm ja das wäre meine frage gewesen..
System64 gleich = Hardlinks, Symlinks und Softlinks ?

Seltsam ist nur ich habe den System64 Ordner nicht angelegt und er ist unter W7 vorhanden.
Und nur darüber lasen sich die Anwendungen starten.
Versuche ich die Datei unter System32 zu öffnen dann funktioniert es nicht wie schon beschrieben.
Die Datei wird nicht gefunden oder gelesen.

Zitat:

Die Dateien darin gibt es aber nur einmal

Korrekt! Sind nur links zur Original Datei.

Zitat:

•Redirection temporär deaktivieren via MSDN-Library durchsuchenWow64DisableWow64FsRedirection und danach wieder zurückstellen mit MSDN-Library durchsuchenWow64RevertWow64FsRedirection.

OK muss dann zurück rudern das wäre dann die richtige Lösung.

Hier gibt es ein Commandline Tool was genau deine beschriebene Methode zur Verfügung stellt.
Oder man programmiert sich das eben selbst.

Ehrlich gesagt das ist ein Caos mit dem SysWOW64 kram. ;)

gruss

[Dalai]

Zitat:

Zitat von EWeiss (Beitrag 1392607)

Hmmm ja das wäre meine frage gewesen..
System64 gleich = Hardlinks, Symlinks und Softlinks ?

Symlink oder Junction kommen dafür in Frage. Theoretisch könnten es auch Hardlinks sein, dann wäre das Verzeichnis \Windows\System64 ein normales Verzeichnis (und alle Dateien darin eben hart verlinkt).

Zitat:

Seltsam ist nur ich habe den System64 Ordner nicht angelegt und er ist unter W7 vorhanden.

Irgendein Tool in der Vergangenheit benutzt, und damit vielleicht unbewusst dieses Verzeichnis generiert?

Zitat:

Korrekt! Sind nur links zur Original Datei.

Oder eben die exakt selbe Datei. Wenn es ein Hardlink sein sollte, würde man das am Hardlink-Count erkennen. Sollte das gesamte Verzeichnis \Windows\System32 nach \Windows\System64 verlinkt sein (Junction oder Symlink), wäre es dieselbe Datei mit demselben Eintrag in der MFT mit einem Hardlink-Count von 1. Vielleicht mal mit NTFSLinksView auf das Verzeichnis \Windows\System64 und/oder die SnippingTool.exe schauen?

Zitat:

Ehrlich gesagt das ist ein Caos mit dem SysWOW64 kram. ;)

Chaos ist richtig, aber wenn man es einmal verstanden hat, ist es gar nicht so schwer. Nichtsdestotrotz ist die Umsetzung im Windows ziemlich bescheiden und teilweise fehleranfällig, und vielleicht hätte man es besser machen können (auch wenn ich die Frage des Wie mangels Wissen nicht beantworten kann und will).

Grüße
Dalai

[EWeiss]

Zitat:

Irgendein Tool in der Vergangenheit benutzt, und damit vielleicht unbewusst dieses Verzeichnis generiert?

Möglich weis es nicht mehr zu lange her ;)
OT:
Wenn ich das Verzeichnis lösche, lösche ich dann auch die original Dateien unter System32?
Auf der anderen Seite könnte es große Auswirkungen auf mein gesamtes System haben da ich nicht mehr weis warum das Verzeichnis angelegt wurde.

Was mir nebenbei einfällt.. sollte da wohl noch was an meinem Programm OTTB feilschen.
Also prüfen ob die Anwendung der Verknüpfung 64Bit ist oder nicht. (wird schwierig)
Da ich jetzt feststellen muss das sich diese dann mit meinem Programm auch nicht ausführen lassen und die Icons falsch eingelesen werden.
OK! Ist eine andere Sache.

Zitat:

Vielleicht mal mit NTFSLinksView auf das Verzeichnis \Windows\System64 und/oder die SnippingTool.exe schauen?

junction ;)

gruss

[HolgerX]

Hmm..


Das funktioniert:

Zitat:

Zitat von ventiseis (Beitrag 1392591)

Eventuell so:

Delphi-Quellcode:

  ShellExecute(Application.Handle, 'open', pchar(ExpandEnvStr('%windir%\sysnative\SnippingTool.exe')), nil, nil, sw_show);

Siehe hier:

• ExpandEnvStr
• Sysnative

Delphi-Quellcode:

uses
  ShellApi;


// https://stackoverflow.com/questions/2833021/how-to-get-absolute-path-from-path-with-system-path-variables
function ExpandEnvStr(const szInput: string): string;
  const
    MAXSIZE = 32768;
  begin
    SetLength(Result,MAXSIZE);
    SetLength(Result,ExpandEnvironmentStrings(pchar(szInput),
      @Result[1],length(Result)) - 1);
  end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  ShellExecute(Application.Handle, 'open', pchar(ExpandEnvStr('%windir%\sysnative\SnippingTool.exe')), nil, nil, sw_show);
end;

Getestet mit Delphi 6 (somit 32 bit).

SnippingTool wird gestartet...


Ein 'System64' hab ich nicht unter meinem 64Bit W8.1, nur das bekannte 'SysWOW64'...

[EWeiss]

Das funktioniert auch es werden sogar meine Icons korrekt eingelesen.
Aus dem Forum hier..

Musste aber noch einiges ändern.. aber was soll's.

Delphi-Quellcode:

function ChangeFSRedirection(bDisable: BOOL): BOOL;
type
  TWow64DisableWow64FsRedirection = function(var Wow64FsEnableRedirection: BOOL): BOOL; stdcall;
  TWow64EnableWow64FsRedirection = function(var Wow64FsEnableRedirection: BOOL): BOOL; stdcall;

function Is64Bit: Boolean;
var
  Reg: TRegistry;
begin

  Reg := TRegistry.Create;
  Reg.RootKey := HKEY_LOCAL_MACHINE;
  Result := Reg.KeyExists('\SOFTWARE\Wow6432Node');
  Reg.Free;
end;

var
  Handle: THandle;
  Wow64DisableWow64FsRedirection: TWow64DisableWow64FsRedirection;
  Wow64EnableWow64FsRedirection: TWow64EnableWow64FsRedirection;
  Wow64FsEnableRedirection: BOOL;
begin

  Result := true;
  if not Is64Bit then
    exit;

  try
    Handle := GetModuleHandle('kernel32.dll');
    @Wow64EnableWow64FsRedirection := GetProcAddress(Handle, 'Wow64EnableWow64FsRedirection');
    @Wow64DisableWow64FsRedirection := GetProcAddress(Handle, 'Wow64DisableWow64FsRedirection');

    if ((Handle <> 0) and (@Wow64EnableWow64FsRedirection <> nil) and
      (@Wow64DisableWow64FsRedirection <> nil)) then

      if bDisable then
        Wow64DisableWow64FsRedirection(Wow64FsEnableRedirection)
      else
      Wow64EnableWow64FsRedirection(Wow64FsEnableRedirection);

  except
    Result := false;
  end;
end;

Delphi-Quellcode:

ChangeFSRedirection(true);
ShellExecuteW(0, nil, PWideChar('C:\Windows\System32\SnippingTool.exe'), nil, nil, SW_SHOW);
ChangeFSRedirection(false);

gruss

[Fukiszo]

Zitat:

Zitat von EWeiss (Beitrag 1392609)

Also prüfen ob die Anwendung der Verknüpfung 64Bit ist oder nicht. (wird schwierig)

Nö, total einfach, PE Header auslesen und auswerten.

Grüße

[Bornholdt]

Hallo zusammen,
danke für Euer zahlreiches Feedback.

Anbei die Lösung, die bei mir die gewünschten Ergebnisse bringt (inkl. Aufruf von quickassist.exe)


// Begin Helferfunktion zum Aufruf SnippingTool und quickassist
function ExpandEnvStr(const szInput: string): string;
const
MAXSIZE = 32768;
begin
SetLength(Result,MAXSIZE);
SetLength(Result,ExpandEnvironmentStrings(pchar(sz Input),
@Result[1],length(Result)) - 1);
end;


// Aufruf SnippingTool (Screenshot Tool)
procedure Formular.SnippingToolClick(Sender: TObject);
var
kError : Integer;
begin
kError := ShellExecute(Application.Handle, 'open', pchar(ExpandEnvStr('%windir%\sysnative\SnippingToo l.exe')), nil, nil, sw_show);
if kError < 33 then begin
ShowMessage(Format('Die Anwendung kann nicht gestartet werden. Fehlercode: %d!',[kError]));
end;
end;



// Aufruf Quickassist (Teamviewer Ersatz App nur unter Windows 10)
// https://stackoverflow.com/questions/...path-variables
procedure Formular.QuickAssistClick(Sender: TObject);
var
lError : Integer;
begin
lError := ShellExecute(Application.Handle, 'open', pchar(ExpandEnvStr('%windir%\system32\quickassist. exe')), nil, nil, sw_show);
if lError < 33 then begin
ShowMessage(Format('Die Anwendung kann nicht gestartet werden. Fehlercode: %d!',[lError]));
end;
end;



VG !!

[EWeiss]

Zitat:

Zitat von Fukiszo (Beitrag 1392621)

Zitat:

Zitat von EWeiss (Beitrag 1392609)

Also prüfen ob die Anwendung der Verknüpfung 64Bit ist oder nicht. (wird schwierig)

Nö, total einfach, PE Header auslesen und auswerten.

Grüße

Brauche ich nicht muss nur prüfen ob win64 oder nicht.
Hat sich für mich auch erledigt so wie du sehen kannst ;)
Ich jage alle Dateien durch die ChangeFSRedirection und gut ist.

Zitat:

Anbei die Lösung, die bei mir die gewünschten Ergebnisse bringt (inkl. Aufruf von quickassist.exe)

@Bornholdt Es wäre nett wenn du die Delphi tags verwenden würdest..
Danke!

gruss

[Fukiszo]

@EWeiss: Ja schon klar, aber angenommen, nurmal angenommen, ich prüfe den PE-Header ob 32/64 um dann dein ChangeFSRedirection(32/64) zu bestimmen/benutzen. So meint ich es. (bzw oder die andere methode von stackoverflow)
Oder sobald \system32\ drinn vorkommt ohne PE prüfung, oder oder oder, wie immer gibt es mehr als einen Weg um ans Ziel zu kommen :-)


Ich pers. mag beide Varianten und hab sie in meine Tipps Datenbank aufgenommen.

Grüße

[EWeiss]

Zitat:

wie immer gibt es mehr als einen Weg um ans Ziel zu kommen

Dito!

gruss

[Dalai]

Zitat:

Zitat von Fukiszo (Beitrag 1392631)

@EWeiss: Ja schon klar, aber angenommen, nurmal angenommen, ich prüfe den PE-Header ob 32/64 um dann dein ChangeFSRedirection(32/64) zu bestimmen/benutzen. [...]Oder sobald \system32\ drinn vorkommt ohne PE prüfung

Auch keine gute Idee. Es sind noch eine ganze Reihe anderer Verzeichnisse von der Redirection betroffen, und die können sich sogar mit jeder neuen Windows-Version ändern. Zudem können 64 bit Executables/DLLs auch auf einem 32 bit Programm rumliegen, da gibt's aber keine Redirection zu deaktivieren. Nicht die Zieldatei ist ausschlaggebend, sondern das OS, unter dem ein Programm läuft. Auswertung des PE Headers ist in Ordnung, sofern man das nicht als Indikator verwendet, unter welchem OS ein Programm läuft.

@EWeiss:
Windows bietet bereits eine Funktion zur Bestimmung der Bittigkeit: IsWow64Process. Und bzgl. Wow64DisableWow64FsRedirection: Nimm besser LongBool sowohl für Rückgabe als auch Parameter. Wenn du hier im Forum nach meinen Beiträgen suchst, die diesen Funktionsnamen enthalten, findest du eine Implementation von mir (mittlerweile allerdings leicht überarbeitet).

Und immer schön darauf achten, die Redirection nur kurzzeitig zu deaktivieren. Denn es funktioniert z.B. nicht, eine DLL aus \Windows\System32 zu laden, während sie deaktiviert ist (weil 32 bit Prozesse nunmal keine 64 bit DLLs laden können, und umgekehrt).

Noch kurz bzgl. des Löschens des bei dir vorhandenen System64: Wenn es wirklich eine Junction ist, kann man die löschen. Ich rate aber dazu, einen Dateimanager (oder die CMD) zu verwenden und nicht den Explorer. Es wird immer wieder behauptet, der Explorer könne nicht sauber mit diesen NTFS-Eigenschaften umgehen und würde bei einem Löschvorgang nicht nur die Junction an sich sondern auch alles entsorgen, worauf die Junction zeigt. Ich hab das irgendwann mal ausprobiert, und konnte das nicht bestätigen. Aber wie sagen die Angelsachsen so schön: Better safe than sorry.

Grüße
Dalai

[EWeiss]

Zitat:

Nimm besser LongBool sowohl für Rückgabe als auch Parameter.

Sage mir bitte mal wo liegt der Unterschied zwischen LongBool oder BOOL.. Vom sichtbaren mal abgesehen.
Denn beides ist das gleiche.

BOOL: LongBool

Zitat:

Und immer schön darauf achten, die Redirection nur kurzzeitig zu deaktivieren.

Sie wird einmalig deaktiviert bis alle Icons verarbeitet und zugewiesen wurden incl. Icons, Pfade und so weiter.
Und dann nur einmal beim starten der Anwendung danach direkt wieder ein.

Zitat:

Windows bietet bereits eine Funktion zur Bestimmung der Bittigkeit: MSDN-Library durchsuchenIsWow64Process.

Ok das könnte ich noch ändern.
Nein ich denke der weg über die registry ist die bessere Alternative.

Zitat:

Note that this technique is not a reliable way to detect whether the operating system is a 64-bit version of Windows because the Kernel32.dll in current versions of 32-bit Windows also contains this function.

gruss

[Dalai]

Zitat:

Zitat von EWeiss (Beitrag 1392743)

Sage mir bitte mal wo liegt der Unterschied zwischen LongBool oder BOOL.. Vom sichtbaren mal abgesehen.
Denn beides ist das gleiche.

Oh, du hast recht. Hab ich mit Boolean verwechselt, das nur ein Byte groß ist, LongBool (und BOOL) ist aber 4 Byte.

Zitat:

Nein ich denke der weg über die registry ist die bessere Alternative.

Zitat:

Note that this technique is not a reliable way to detect whether the operating system is a 64-bit version of Windows because the Kernel32.dll in current versions of 32-bit Windows also contains this function.

Äh, ja und jetzt rate mal, was die Funktion auf einem 32 bit Windows zurückgibt... Tip: immer False. [ADD]Zudem bezieht sich dieser Satz auf die beiden vorhergehenden, in denen es darum geht, die Funktion dynamisch mit GetProcAddress zu ermitteln - und das allein ist kein sinnvoller Weg, um zu ermitteln, ob es ein 64 bit OS ist. Nur der Aufruf der Funktion ist es.[/ADD]

Grüße
Dalai

[EWeiss]

Zitat:

Zitat von Dalai (Beitrag 1392749)

Zitat:

Zitat von EWeiss (Beitrag 1392743)

Sage mir bitte mal wo liegt der Unterschied zwischen LongBool oder BOOL.. Vom sichtbaren mal abgesehen.
Denn beides ist das gleiche.

Oh, du hast recht. Hab ich mit Boolean verwechselt, das nur ein Byte ist, LongBool (und BOOL) ist aber 4 Byte.

Zitat:

Nein ich denke der weg über die registry ist die bessere Alternative.

Zitat:

Note that this technique is not a reliable way to detect whether the operating system is a 64-bit version of Windows because the Kernel32.dll in current versions of 32-bit Windows also contains this function.

Äh, ja und jetzt rate mal, was die Funktion auf einem 32 bit Windows zurückgibt... Tip: immer False.

Grüße
Dalai

Logisch.
Aber MS weist darauf hin das man sie unter einem 32Bit System nicht verwenden soll.
Oder interpretiere ich das falsch?
Glaube nicht.

BOOL ist kein 4Byte groß sondern BOOL ist definiert als LongBool somit ist es das selbe, logischerweise auch in der Byte anzahl.

gruss

[Dalai]

Zitat:

Zitat von EWeiss (Beitrag 1392750)

Aber MS weist darauf hin das man sie unter einem 32Bit System nicht verwenden soll.
Oder interpretiere ich das falsch?
Glaube nicht.

Nein, so ist das nicht gemeint. Siehe meine Ergänzung im vorherigen Post. Ich verwende diese Funktion übrigens schon seit Jahren, um zu bestimmen, ob meine Programme (oder TC-Plugins) unter WOW64 laufen oder nicht.

[EDIT]

Zitat:

BOOL ist kein 4Byte groß sondern BOOL ist definiert als LongBool somit ist es das selbe, logischerweise auch in der Byte anzahl.

LongBool ist 32 bit groß, also 4 Byte. Einfach mal im DocWiki schauen: LongBool.
[/EDIT]

Grüße
Dalai

[EWeiss]

Zitat:

Zitat von Dalai (Beitrag 1392751)

Zitat:

Zitat von EWeiss (Beitrag 1392750)

Aber MS weist darauf hin das man sie unter einem 32Bit System nicht verwenden soll.
Oder interpretiere ich das falsch?
Glaube nicht.

Nein, sie weisen nicht darauf hin. Siehe meine Ergänzung im vorherigen Post. Ich verwende diese Funktion übrigens schon seit Jahren, um zu bestimmen, ob meine Programme (oder TC-Plugins) unter WOW64 laufen oder nicht.

Grüße
Dalai

OK nicht weil ich recht haben will aber was spricht gegen das auslesen der Registry?
So muss ich zweimalig auf die Kernel32 zugreifen nur um einen wert in Erfahrung zu bringen.
Ich öffne ja schon für den Pfad die Kernel.

gruss

[Dalai]

Zitat:

Zitat von EWeiss (Beitrag 1392755)

OK nicht weil ich recht haben will aber was spricht gegen das auslesen der Registry?

Wer sagt, dass es nicht auch auf einem 32 bit Windows den Zweig HKLM\Software\Wow6432Node geben kann? Vielleicht aus Versehen durch Import einer falschen .reg Datei angelegt worden? Zuverlässig finde ich das nicht. Und die kernel32.dll ist üblicherweise in jedem Prozess geladen, insofern macht das keinen Laufzeitunterschied, ob man nun eine Funktion mehr daraus ausführt.

[EDIT]
Ach, und noch eine Sache: Auch die Registry unterliegt einer Redirection. Unter einem 64 bit OS landen alle Zugriffe auf HKLM\Software eines 32 bit Programms in HKLM\Software\Wow6432Node, sofern man den Schlüssel nicht mit einem bestimmten Flag öffnet.
[/EDIT]

Grüße
Dalai

[EWeiss]

Zitat:

Zitat von Dalai (Beitrag 1392756)

Zitat:

Zitat von EWeiss (Beitrag 1392755)

OK nicht weil ich recht haben will aber was spricht gegen das auslesen der Registry?

Wer sagt, dass es nicht auch auf einem 32 bit Windows den Zweig HKLM\Software\Wow6432Node geben kann? Vielleicht aus Versehen durch Import einer falschen .reg Datei angelegt worden? Zuverlässig finde ich das nicht. Und die kernel32.dll ist üblicherweise in jedem Prozess geladen, insofern macht das keinen Laufzeitunterschied, ob man nun eine Funktion mehr daraus ausführt.

Grüße
Dalai

OK dann werde ich es ändern wollte nur nochmal nachfragen ;)

gruss

[EWeiss]

Zitat:

LongBool ist 32 bit groß, also 4 Byte. Einfach mal im DocWiki schauen: Delphi-Referenz durchsuchenLongBool.

Du verstehst nicht was ich meine oder?

Nochmal! Es gibt kein BOOL mit 4Bytes..

Denn BOOL ist unter Delphi eine Variable definiert als LongBool.
Du verstehst den Unterschied?

LongBool ist 4Byte aber wenn BOOL nicht als LongBool definiert wäre, wäre BOOL nothing.

Schau doch einfach mal in die Windows Unit.

Delphi-Quellcode:

  BOOL = LongBool;
  {$EXTERNALSYM BOOL}
  PBOOL = ^BOOL;
  {$EXTERNALSYM PBOOL}

Es gibt kein BOOL und LongBool, es gibt nur LongBool.
Und Bool ist als LongBool definiert.

gruss

[Dalai]

[OT]

Zitat:

Zitat von EWeiss (Beitrag 1392759)

Du verstehst nicht was ich meine oder?

Wenn BOOL nur ein Alias für LongBool ist, sind die beiden auch gleich groß. Da LongBool 32 bit lang ist, ist es BOOL auch. Ob das nun ein eigener Typ ist oder nicht, spielt für die Länge keine Rolle. Und nur auf die Länge wollte ich hinaus, denn genau die ist entscheidend für den Aufruf mancher (API-)Funktionen. Ich hatte ja bereits gesagt, dass ich es mit Boolean verwechselt habe, das nur ein Byte lang ist. Das war's von meiner Seite mit der Haarspalterei.

[/OT]

Grüße
Dalai

[EWeiss]

Zitat:

Das war's von meiner Seite mit der Haarspalterei.

Hat damit nichts zu tun.

BOOL ist ohne Longbool nun mal nichts da kannst du drum rum reden wie du willst.
Den Datentyp BOOL 4Byte gibt es unter Delphi nicht das ist Fakt!

BOOL ist eine Bezeichnung ohne irgendeinen wert.

EDIT:
Ich bin fertisch ;)

gruss

[Fukiszo]

OT @Dalai: TC-Plugins = Total Commander? Falls ja, ich liebe dieses Programm und seine simple Erweiterbarkeit, kann man sich irgendwo Deine Plugins anschauen/runterladen? Grüße

[Dalai]

[OT]

Zitat:

Zitat von Fukiszo (Beitrag 1392771)

OT @Dalai: TC-Plugins = Total Commander?

Ja, TC = Total Commander. Die Schreibweise ist bei mir so drin, dass ich es gar nicht mehr wahrnehme, wenn ich TC schreibe :lol:.

Zitat:

Falls ja, ich liebe dieses Programm und seine simple Erweiterbarkeit, kann man sich irgendwo Deine Plugins anschauen/runterladen?

Kann man bei totalcmd.net finden. Ich habe noch Ideen für zwei weitere Plugins, komme aber dummerweise seit mehr als zwei Jahren mangels Zeit einfach nicht dazu... :cry:

[/OT]

Grüße
Dalai