64bit 32Bit erkennung

[Urshak]

Hallo wie erkenn ich ein 64/32 Bit System ich will registry werte auslesen und in 64 bit systemen ist unter HKLM/Software noch ein zusätliches Verzeichnis Wow6432Node so jetzt hab ich dann 2 verschiedene Syntaxen für 64bit und 32bit deshalb brauch ich ein PGR
welches erkennt ob man ein 64 oder 32 bit system hat wie stell ich das an gibts dafür auch einen eintrag in der registry?

P.S Bin Anfänger deshalb bitte ich um einen Quellcode

Danke In Voraus

[Urshak]

Ich benutzte C ,batch geht auch

[Jochen Kalmbach]

Es ist eigentlich ganz einfach:
Wenn Du selbst eine 64-Bit Aplikation bist, dann läufst Du auf einem 64-Bit System.

Bist Du hingegen eine 32-Bit Applikation, so rufe "IsWow64Process" auf...

Ich verstehe trotzdem nicht ganz, für was Du dies wissen musst...
Bzgl. Registry siehe meinen Artikel über wow64:
http://www.codeproject.com/KB/system/Reflection.aspx

[Urshak]

#include <windows.h>
#include <stdio.h>

typedef BOOL (WINAPI *LPFN_ISWOW64PROCESS) (HANDLE, PBOOL);

LPFN_ISWOW64PROCESS fnIsWow64Process;

BOOL IsWow64()
{
    BOOL bIsWow64 = FALSE;

    fnIsWow64Process = (LPFN_ISWOW64PROCESS)GetProcAddress(
        GetModuleHandle(TEXT("kernel32")),"IsWow64Process");

    if (NULL != fnIsWow64Process)
    {
        if (!fnIsWow64Process(GetCurrentProcess(),&bIsWow64))
        {
            // handle error
        }
    }
    return bIsWow64;
}

void main()
{
    if(IsWow64())
        printf("Running on WOW64\n");
    else printf("Running on 32-bit Windows\n");
}

es klappt wunderbar aber ich versteh nur die Typendefinition für Bool.
p.s was bedeutet handle?
nunmal mein code

#include <stdio.h>
#include <windows.h>
main(){
int x=IsWow64Process;
printf("%i",x);
}

das funktioniert nicht
können sie meinen Quellcode so ergänzen und ein bisschen erklären??

[Jochen Kalmbach]

Was tut an dem Beispeil in der Doku nicht?

[merano]

Urshak schrieb:

das funktioniert nicht
können sie meinen Quellcode so ergänzen und ein bisschen erklären??

Das erste Beispiel funktioniert doch ?

Das zweite Beispiele sollte evtl. so aussehen:

BOOL x= IsWow64(); 

if(x == TRUE)
  cout << "Das OS unterstützt 64 Bit" << endl;

Bem: Printf ist nicht threadsave unter Windows und daher oft nicht einsetzbar.

War die Frage was IsWow64() macht ?
Zunächst die Einsprungstelle im Kernel suchen mit GetProcAddress().
Wenn die Funktion existiert (Zeiger != NULL) diese aufrufen und das Ergebnis zurückliefern.

[Martin Richter]

merano schrieb:

Bem: Printf ist nicht threadsave unter Windows und daher oft nicht einsetzbar.

Für MS-VC ist dies defintiv falsch.

[merano]

Hallo Martin,

da ich eine sehr hohe Meinung von Dir habe vermute ich das Du genau weist wovon Du sprichst ..

Martin Richter schrieb:

Für MS-VC ist dies defintiv falsch.

Ab welcher Version VC hat sich das geändert ?

Nachdem ich mit Multithreads und Dual bzw. Quadcore CPU plötzlich übelste Effekte mit einfachsten Win32 Testprogrammen hatte, habe ich das wörtlich so im MSDN gefunden.

[Martin Richter]

Die CRT liegt als Multithreading Library seit VC6 vor (evtl. schon früher an VC4 kann ich mich nicht mehr genau erinnern)!
Man muss eben die Multithreading-CRT auch nutzen. Seit VS-2005 gibt es nur noch die Multithreading-CRT!

printf kann wie alle anderen CRT Funktionen von beliebig vielen Threads gleichzeitig ausgeführt werden. Ob die Ausgabe das gewünschte Ergebnis bringt ist was anderes
Was anderes sind die Daten selber. Diese müssen natürlich threadsicher übergeben werden...

Zu Deinen Problemen:
Wo bitte steht, dass printf nicht multithreadingfähig ist?
Du hattest wirklich mehere Threads n einem Consolen Programm?
Du hast aus mehreren Threads gleichzeitig printf genutzt? Warum macht doch keinerlei Sinn?

[merano]

Martin Richter schrieb:

Seit VS-2005 gibt es nur noch die Multithreading-CRT!

Es war definitiv VisualStudio2005, allerdings vermutlich ohne SP1 unter WinXP.

Seitdem meide ich printf() und Co.

Habe das Programmgerüst wiedergefunden, kann den Fehler aber mit SP1 nicht reproduzieren.

Hinweise das es Probleme gibt finden sich auch heute noch, z.B. hier:

The MyThreadFunction function avoids the use of the C run-time library (CRT), as many of its functions are not thread-safe, particularly if you are not using the multithreaded CRT.

http://msdn.microsoft.com/en-us/library/ms682516(VS.85).aspx

Die Stelle wo speziell ANSI oder printf() genannt wurde habe ich bisher nicht wiedergefunden - vielleicht weil sie mittlerweile überholt ist ?

--

Bei dem Test ging es darum die Auswirkungen von unterschiedlichen Prioritäten bei Verwendung mehrerer Threads zu zeigen. Ausserdem sollte die Notwendigkeit
von Semaphoren gezeigt werden - da Prioritäten bei Multicore so schöne Nebenwirkungen haben. Auch extrem niedrig priorisierte Threads bekommen ohne Probleme Rechenzeit, da ja immer ein Core frei ist ...

Nachdem ich alle printf() mit Mutex-Semaphoren geschützt hatte lief es damals auch mit printf() wie erwartet, aber das ist ja keine dolle Lösung ...

Achja, leider spielen die Prioritäten in der Warteschlange einer Semaphore keine Rolle, sodas die ganze Sache so nicht nutzbar ist. Idee?

[Mmacher]

Hallo merano,
Dein verlinkter Hinweis ist schon korrekt, Du hättest den Satz nur bis zum Ende lesen sollen (hier fett hervorgehoben):

merano schrieb:

The MyThreadFunction function avoids the use of the C run-time library (CRT), as many of its functions are not thread-safe, particularly if you are not using the multithreaded CRT.

D.h. mit der Compiler-Option "multithreaded CRT" bzw "/MT" ist die CRT-Bibliothek 100%ig threadsicher.

Es gibt in der Tat allerdings Probleme, die speziell im Zusammenhang bei Thread-Erstellung auftreten, aber das ist eine andere Natur.

Für Dich grob zusammengefaßt gilt:
Verwendest Du in Threads die CRT-Funktionen, dann mußt Du Threads mit der CRT-Funktion _beginthreadex() erzeugen.
Denn die Win32API-Funktion CreateThread() erzeugt hierbei beim Beenden von Threads Speicherlecks.
Übrigens, wenn Du Dir die Sourcen von _beginthreadex() anschaust, dann wirst Du feststellen, daß diese nach einer Reihe von Initialisierungen am Ende selbst CreateThread() aufruft.

Hierzu gibts Links, die das ganze ausführlich erörtern. Hab nur nicht in der Hosentasche parat.
[Nachtrag:]
Hier findest Du ein Beitrag von Martin Richter: "CreateThread und die CRT" http://blog.m-ri.de/index.php/2007/11/28/createthread-und-die-crt/
Beitrag von Jeffrey Richter in der Win32 Kolumne von "Microsoft Systems Journal July 1999": http://www.microsoft.com/msj/0799/Win32/Win320799.aspx

HTH,
Martin

[Martin Richter]

1. Warum langsame Mutexe nehmen wenn es um inner Prozess Synch geht und das mit eine CriticalSection 100 mal schnelleer ist.
2. Verstehe ich diesen Satz eher als "speziell wenn keine Multithreaded CRT verwendet wird".

Grundsätzlich ist die CRT multithreadingfähig.
Warum sonst gibt es eben den threadlokal Storage in der CRT, den Du hier erwänst?

[merano]

Natürlich war bei allen Tests die multithreaded CRT ausgewählt.
Leider funktionierte printf() trotzdem nicht. Das Misstrauen bleibt, auch wenn es jetzt scheinbar funktioniert ...

Das es den threadlokal Storage gibt, stellt nicht automatisch SICHER, das alle Funktionen auch thread-safe sind.

Möchte diese Frage an dieser Stelle jetzt aber auch nicht fortsetzen.

Danke für die Tipps und Anregungen.

[314159265358979]

bool on32BitSystem() { return sizeof(void*) == 4; }