läuft Programm unter 32-Bit oder 64-Bit ab ?

[Gerkey]

Habe Programme in der 32-Bit Version erstellt, die nun auch unter 64-Bit ablaufen sollen, was aber Änderungen u.a. beim Umgang mit einer MSACCESS Datenbank erfordert.
Gibt es eine Möglichkeit im Programm abzufragen, unter welcher Version es gerade abläuft ?

[Uwe Raabe]

Zitat:

Zitat von Gerkey (Beitrag 1373506)

Gibt es eine Möglichkeit im Programm abzufragen, unter welcher Version es gerade abläuft ?

Gibt es: IsWow64Process

[p80286]

Könntest Du das ein wenig ausführlicher erklären?
Ich arbeite seit Jahren mit 32-Bit-Kompilaten sowohl unter 32-Bit als auch 64-Bit Betriebssystemen, ohne Änderungen an den Programmen vor zu nehmen.

Gruß
K-H

[himitsu]

Es gibt für 32 Bit-Programme in einem 64 Bit-Windows, also unter WoW64 einige "Umleitungen", in der Registry und im Dateisystem.

Vorallem bei Dingen, die es als 32 und 64 Bit gibt, kommt es schonmal vor dass es da Prolemchen gibt, wenn sie von Beidem angesprochen werden können. (hier die DB)

Also passend zum IsWow64Process würde ich noch Wow64DisableWow64FsRedirection erwähnen.

[Der schöne Günther]

Zitat:

Zitat von himitsu (Beitrag 1373521)

Also passend zum IsWow64Process würde ich noch Wow64DisableWow64FsRedirection erwähnen.

Die Doku sagt

Zitat:

This value is for system use only. To avoid unpredictable behavior, do not modify this value in any way.

Was würdest du sagen wozu man das braucht?

[himitsu]

Dann hätten die das eben als geheime Funktion nicht in die Doku aufnehmen sollen. :stupid:

Zitat:

Zitat von Der schöne Günther (Beitrag 1373523)

Was würdest du sagen wozu man das braucht?

Wenn man absichtlich auf bestimmte Verzeichnisse zugreifen will/muß, aber das System einen da standardmäßig immer umleitet.

[Luckie]

Ich habe es zum Beispiel bei meinem Usermanger benötigt, damit er auch unter 64-Bit funktioniert und die Registryeinträge in den richtigen Zweig schreibt.

[Zacherl]

Zitat:

Zitat von Uwe Raabe (Beitrag 1373509)

Zitat:

Zitat von Gerkey (Beitrag 1373506)

Gibt es eine Möglichkeit im Programm abzufragen, unter welcher Version es gerade abläuft ?

Gibt es: IsWow64Process

Die API ist aber etwas tricky:

Zitat:

A pointer to a value that is set to TRUE if the process is running under WOW64. If the process is running under 32-bit Windows, the value is set to FALSE. If the process is a 64-bit application running under 64-bit Windows, the value is also set to FALSE.

Hier gibt es jetzt zwei Fälle, in denen die API "false" wird:

1. 32-Bit Windows -> Eigener Prozess ist zwingend auch 32-Bit
2. 64-Bit Prozess

Macht also keine sichere Aussage darüber, ob der eigene Prozess jetzt unter 32 oder 64-Bit läuft. Dafür müsste man entweder mit konditionalen Compilerdirektiven arbeiten, oder zur Laufzeit ermitteln, ob Windows selbst 32 oder 64 Bit ist.

[Uwe Raabe]

Zitat:

Zitat von Zacherl (Beitrag 1373562)

Hier gibt es jetzt zwei Fälle, in denen die API "false" wird:

1. 32-Bit Windows -> Eigener Prozess ist zwingend auch 32-Bit
2. 64-Bit Prozess

Die Originalfrage wird aber genau durch diesen Rückgabewert beantwortet, denn das Programm ist per Vorgabe 32-Bit. Zur Erinnerung:

Zitat:

Zitat von Gerkey (Beitrag 1373506)

Habe Programme in der 32-Bit Version erstellt, die nun auch unter 64-Bit ablaufen sollen, was aber Änderungen u.a. beim Umgang mit einer MSACCESS Datenbank erfordert.
Gibt es eine Möglichkeit im Programm abzufragen, unter welcher Version es gerade abläuft ?

[himitsu]

Es sagt ja auch "Ich laufe im 32 Bit-Subsystem eines 64 Bit-Windows", also muß es für True zwangsläufig auch ein 32 Bit-Programm sein.
WoW64 = Windows (32) on Windows 64

64 Bit-Programme laufen zwangsläufig in einem 64 Bit-Windows
und 32 Bit-Programme können damit abfragen, ob sie in einem 32 Bit-Windows ober im Subsystem eines 64 Bit-Windows laufen.

Delphi-Quellcode:

{$IF SizeOf(Pointer) = 4}
{$IFDEF CPUX86}
{$IFDEF WIN32}

{$IF SizeOf(Pointer) = 8}
{$IFDEF CPUX64}
{$IFDEF WIN64}

Spaßig wird es, wenn es mal ein 128 Bit-Windows gibt und 32 Bit-Windowse dann auch noch leben.

[Zacherl]

Zitat:

Zitat von Uwe Raabe (Beitrag 1373563)

Die Originalfrage wird aber genau durch diesen Rückgabewert beantwortet, denn das Programm ist per Vorgabe 32-Bit.

Da habe ich die Frage scheinbar falsch verstanden. Ich ging davon aus, dass er sowohl für 32 als auch für 64 Bit kompilieren will.

[Gerkey]

Mit der Bitte um Nachsicht für einen Noch-Anfänger : Wie setze ich denn "isWOW64Process" im Programm ein ?
Gibt's es irgendwo einen Beispiel-Code ?

Gerkey

[Uwe Raabe]

Zitat:

Zitat von Gerkey (Beitrag 1374031)

Gibt's es irgendwo einen Beispiel-Code ?

Delphi-Quellcode:

  
  function IsWOW64: BOOL;
  begin
    IsWow64Process(GetCurrentProcess, Result);
  end;

[Gerkey]

Meine Delphi - Kenntnisse und Fähigkeiten sind wohl schon wieder an ihre Grenzen gestoßen ! Wenn ich die Funktion "IsWOW64" in der angegebenen Form ins Programm übernehme, erhalte ich folgende Meldung: "Es gibt keine überladene Version von ‘IsWOW64Process‘, die man mit diesen Argumenten aufrufen kann !".
Gibt es denn irgendwo eine Dokumentation, die mir weiterhelfen kann, ohne dass ich Euch Experten mit offensichtlich banalen Fragen bemühen muss ?

Gerkey

[Uwe Raabe]

Ich habe jetzt gerade kein XE zur Hand, daher passt mein Code für Tokyo. Schau doch mal in der Windows.pas nach der Deklaration von IsWow64Process. Hier sieht das so aus:

Delphi-Quellcode:

function IsWow64Process(hProcess: THandle; Wow64Process: PBOOL): BOOL; overload; stdcall;
function IsWow64Process(hProcess: THandle; var Wow64Process: BOOL): BOOL; overload; stdcall;

Zeig doch mal die Deklaration bei dir.

Falls das zweite Overload noch nicht da ist, geht es eventuell auch so:

Delphi-Quellcode:

function IsWOW64: BOOL;
begin
  IsWow64Process(GetCurrentProcess, @Result);
end;

[HolgerX]

Hmm..

Da IsWow64Process erst ab einem späteren Delphi verfügbar ist, nutze ich folgende Funktion, um festzustellen, ob meine App in einer 64Bit-Umgebung läuft.. (Benutze halt noch D6 Prof und werde NICHT zur Starter wechseln !) )

(Keine Ahnung mehr, wo ich den herhabe.. ;) )

Delphi-Quellcode:

function IsWow64A: Boolean;
type
  TIsWow64Process = function( // Type of IsWow64Process API fn
    Handle: Windows.THandle; var Res: Windows.BOOL ): Windows.BOOL; stdcall;
var
  IsWow64Result: Windows.BOOL; // Result from IsWow64Process
  IsWow64Process: TIsWow64Process; // IsWow64Process fn reference
begin
  // Try to load required function from kernel32
  IsWow64Process := Windows.GetProcAddress(Windows.GetModuleHandle('kernel32'), 'IsWow64Process');

  if Assigned(IsWow64Process) then begin
    // Function is implemented: call it
    if not IsWow64Process(Windows.GetCurrentProcess, IsWow64Result) then
      raise Exception.Create('IsWow64: bad process handle');

    Result := IsWow64Result; // Return result of function
  end else
    // Function not implemented: can't be running on Wow64
    Result := False;
end;

[himitsu]

Dieser Code ist aber ein schlechtes Beispiel.

Da verschwendet man Minuten, nur um dann mitzubekommen, dass maximal der letzte Kommentar halbwegs wichtige Informationen enthält.
Alles davor ist absolut sinnlos und stellt nur doppelte Informationen für den eigentlich "selbsterklärenden Code dar.
Wichtige Informationen gehen durch Sinnlose Kommentare schnell mal verloren, bzw. man sieht sie garnicht erst, weil man keine Lust mehr hat sich ständig sinnloses Zeug durchzulesen.

Im Gegenzug fehlt dafür die Beschreibung der Fuktion selbst und IsWow64A ist auch falsch, da es hier "dynimisch" implementiert wurde und nicht als ANSI.

Delphi-Quellcode:

/// <summary> Determines whether the specified process is running under WOW64.<br /> WOW64 is the x86
/// emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows </summary>
function IsWow64: Boolean;
type
  TIsWow64Process = function(Handle: THandle; var Res: BOOL): BOOL; stdcall;
var
  IsWow64Process: TIsWow64Process;
  IsWow64Result: BOOL;
begin
  IsWow64Process := GetProcAddress(GetModuleHandle('kernel32'), 'IsWow64Process');
  if Assigned(IsWow64Process) then begin
    if not IsWow64Process(GetCurrentProcess, IsWow64Result) then
      RaiseLastOSError;  //RaiseLastWin32Error;  //raise Exception.Create(SysErrorMessage(GetLastError));
    Result := IsWow64Result;
  end else
    Result := False;  // Function not implemented: can't be running on Wow64
end;

Oder als kurzer Inlinetype.

Delphi-Quellcode:

var
  IsWow64Process: function(Handle: THandle; var Res: BOOL): BOOL; stdcall;
  IsWow64Result: BOOL;

So würde explizit ANSI (A) oder Unicode (W) verwendet.
Das Andere passt sich jeweils an die vom Delphi "standardmäßig" verwendete API-Version an. (Unicode seit D2009)

Delphi-Quellcode:

IsWow64Process := GetProcAddressA(GetModuleHandleA('kernel32'), 'IsWow64Process');

IsWow64Process := GetProcAddressW(GetModuleHandleW('kernel32'), 'IsWow64Process');

Delphi-Quellcode:

/// <summary>

ist die etwas menschenlesbare Version des DocInsight, was die Erweiterung zum HelpInsight darstellt.
Normal z.B. so:

Delphi-Quellcode:

// Determines whether the specified process is running under WOW64.
// WOW64 is the x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows

HelpInsight : Das zeigt als Hint im Delphi die Funktionsdeklaration an.
DocInsight : Das zeigt stattdessen explizite HilfeInfos an (DelphiDoc ala PHPDoc)
Documentation Insight : erweiteres HelpInsight samt integriertem Editor und Hilfegenerator (Dokumentierter Code -> Programm-Hilfe ala .hlp, .chm usw.) ... leider hatte Delphi das nur 2 Jahre lang direkt integriert und hat nur wieder nur die "manuellen" Code-Vorlagen dabei

[HolgerX]

Hmm..

@himitsu

Wieso ist der Code blödsinn?
In D6 gibt es keine Definition von IsWow64Process.

Unter älteren OS (vor XP SP2) gibt es auch diese Funktion nicht in kernel32. (Auch wenn das heute kaum noch jemanden iterressiert, jedoch haben wir tatsächlich noch Kunden mit W2K-Rechnern..)
Diese Funktion gibt es auch auf 32Bit-Systemen, somit sollte das 'Nichtvorhandensein' heute die Ausnahme sein.

Dass er nicht optimiert ist, kann sein.. Ist halt nur Copy/Paste und funktioniert.
Dass hier GetProcAddress statt GetProcAddressA obwohl am Funktionskopf mit 'A' angezeigt verwendet wird..
Ist mir selber noch nicht aufgefallen und macht für die Verwendung eigentlich auch keinen Unterschied.


Das was Dir diese Funktion zurück gibt, ist, dass deine Filezugriffe deiner App umgeleitet werden oder nicht.
Gerade bei Berücksichtigung der von Dir angegebenen Funktion 'Wow64DisableWow64FsRedirection' ist dieser Source brauchbar, da Du damit prüfen kannst, ob dein Disable der Umleitung funtioniert/noch aktiv ist.

Ich nutze sie z.B. um meine Reg-Zugriffe mit einem Flag zu versehen und so ohne 'Wow64DisableWow64FsRedirection' dennoch auf die 64Bit -Pfade zuzugreifen.

Den 'Wow64DisableWow64FsRedirection' hat einen Haken :

Zitat:

For example, DLL loading depends on file system redirection, so disabling file system redirection will cause DLL loading to fail.

Sprich, da kein Redirecting, wird versucht die 64Bit-DLL statt die 32Bit-DLL aus dem umgeleiteten Verzeichnis zu laden und dass dürfte wohl nicht so ganz funktionieren.

Auch für den Zugriff auf System32 (ohne Umleitung) gibt es eine saubere Alternative : %Windir%\Sysnativ\ (oder so, aus dem Kopf geschrieben).

Ich habe z.B. bei der Registry nicht verstranden, wieso es darin Umeitungen gibt.
Bei allen anderen kann ich einen gewissen Sinn (laden der 32Bit DLLs) verstehen.

Jedoch diese für meine 32 Bit App komplett abschalten und dann Gefahr laufen, dass es dann an anderer Stelle nicht klapt ist mir zu heikel.
Da ich 32Bit Apps erstelle nutze ich an den Stellen den meiner Meinung nach sauberen, geziehlten Weg um die Umlenkung zu 'umgehen' ;)

[himitsu]

Der Code ist OK, aber die Kommentierung ist blödsinn. :zwinker:

Kennst du das Problem mit dem Heu und diesem kleinen spitzen Ding?
Die nutzlosen Kommentare sind das Heu und die Nadel (das Wichtige) findet nur der Terence Hill (nur Chuck Norris wird von der Nadel gefunden).

[HolgerX]

@himitsu

Dann muss ich mich bei Dir entschultigen..

Nach dem nun 2/3. Mal (Mit einem kühlen Getränk dazwischen) ist es mir nun auch klar geworden, dass es Dir um die Kommentare/Fehlbenennung gíng und nicht um den Sinn der Funktion.

HelpInsight/DocInsight haben für mich bisher keine Bewandtnis gehabt, Kommentare wurden frei Schnautze erstellt. ;)

Die von mir gepostete Funktion hatte ich irgendwo per Copy/Paste kopiert und habe deren Funktionen auch ohne die vorhandenen Kommentare verstanden, diese jedoch nicht gelöscht/korrigiert... (Waren halt nur Kommentare ;) )

Ich denke, dass ich die Funktion auch eher von

function IsWow64: Boolean;

nach

function IsWow64Redirect: Boolean;

umbenennen würde, da somit auch am Namen direkt klarer erkennbar ist, was sie zurückliefert ;)

[himitsu]

DocInsight gibt es erst seit der neuen IDE (D8/2005).

Da kann man zwar noch viel mehr mit machen, aber alleine schon die paar Grundzweige sind ne nette Geschichte.

Die Delphi-Hilfe wird übrigens auch aus dem Quellcode generiert.
Also es wird eine Funktion in den Code eingebaut und schon ist sie automatisch in der Hilfe drin. (nur mit dem Füllen des Inhaltes hängt es manchmal noch etwas :stupid:)
http://docwiki.embarcadero.com/Libra....StringReplace

Für meine Komponenten / gemeinsamen Funktionen schreibe ich keine extra Hilfe, sondern dokumentiere es direkt im Code.
Vorallem bei Umbauarbeiten kann man so gleich die Hilfe aktuell halten
und das Beste, die Hilfe ist direkt beim Schreiben des Quellcodes verfügbar.
https://youtu.be/zw8SAX2ZrNA?t=3m38s

Links HelpInsight aus PasDoc (DocInsight)
Rechts das normale HelpInsight
und unten rechts das normale CodeInsight.