Suche dringend Leute mit 64Bit Betriebsystemen...

[AHT]

Suche Leute mit 64Bit Betriebsystemen...

Ich bin hier gerade bei einem Test unter 64Bit Windows7 fast rückwärts vom Stuhl gefallen. Ich habe zur Zeit den Verdacht, dass sich da etwas grundlegendes in der API LoadLibrary geändert hat - ich glaube nicht, dass das immer schon so war.
Wenn mein Verdacht sich bestätigt, könnte es vorkommen, das für 64Bit geschriebene Programme (wenn man bestimmte 64Bit Sachen tut) zwar unter Windows7 funktionieren, unter älteren 64Bit Betriebsystemen aber nicht und ganz böse abstürzen - der Grund dafür wäre nicht unbedingt ersichtlich.
Ich möchte nun gerne wissen, ob das, was da in LoadLibrary passiert, in allen 64Bit Systemen so geschieht oder ob es von einem bestimmten Betriebsystem oder einem Update abhängt, dass das geschieht.
Dazu bitte einmal folgendes Programm ausführen und den Button API ausführen anklicken (keinen anderen Button, der Test funktioniert sonst nicht): Download API Test

Bitte nicht auf 32Bit testen, nur auf 64Bit Betriebsystemen (64Bit XP, 64Bit Vista, 64Bit Windows7)!
Ich muss wissen, ob das Programm nach dem Klicken des Buttons API ausführen eine Messagebox über den Status der Internetverbindung zeigt.
Desweiteren müsste ich wissen, auf welchem Betriebsystem der Test lief und ob Windows alle Updates hat (welches Servicepack installiert ist).
Ein Screenshot vom Programm nach dem Klicken des Buttons wäre auch nicht schlecht.

Was tut das Programm:
Es Listet beim starten alle laufenden Prozesse und ruft beim Buttonklick von API ausführen die API InternetGetConnectedState auf. Vorher deaktiviert es die 64Bit-Dateiumleitung.

[ts-soft]

---------------------------
Online!
---------------------------
Internetverbindung besteht!
---------------------------
OK
---------------------------

Win 7 Ultimate x64 SP1

Unterschiede sollte es eigentlich nur zu WinXP x64 geben, welches kaum
kompatibel zu Vista und 7 ist.

[AHT]

Danke dir - welchen Unterschied meine ich denn???

[Sascha Oliver Haak]

@AHT

Win7 Home Premium 64 Bit Servicepack 1 letztes update 3.08.2011

Nach Ausführung öffnet sich eine Messagebox mit

Online!
"Internetverbindung besteht"

Gruß
Sascha

[AHT]

Danke! Wichig wäre vor alln Dingen ista 64Bit!
Ich meine diesen Unterschied...
Windows7:


Vista:


Kann sein dass die unter Vista schon wieder zu sind - bin mir da nicht sicher...
LodLibrary tut da was ganz bestimmtes mit den Threads - das ist wichtig für 64Bit Programmierung.

[Jac de Lad]

Bei mir auch "Online - Internetverbindung besteht".

Windows 7 Ultimate SP1 mit allen Updates.

[AHT]

Danke dir! Kann schon mal sagen, dass das wohl unter allen Windows7 Systemen zutrifft - scheinbar unabhängig von einem Update. Wer noch Vista64Bit hat, bitte mal testen. XP 64Bit wäre auch wichtig.

[ts-soft]

Den Dialog Deines Bildes finde ich nicht, aber ich habe vor dem Start der
Exe 68 Prozesse, nach dem Start dann 69 und das ändert sich erst wieder,
wenn ich Dein Programm beende.

[AHT]

Zur Erklärung:
Es ist erst mal hoch erfreulich, dass das was ich hier in dem Programm tue auf allen 64Bit Systemen mit Windows7 so hundertprozentig läuft - denn normalerweise müsste das Programm (oberflächlich betrachtet) komplett abstürzen...

Was tue ich:
Im Prinzip deaktiviere ich zuerst mittels der API Wow64DisableWow64FsRedirection die automatische Dateiumleitung von 64Bit Betriebsystemen. Danach rufe ich eine API auf - und zwar von einer Windows-DLL, die zur Zeit des Aufrufs noch nicht geladen ist.
Es wird dann automatisch versucht, die DLL beim Aufruf der API nachzuladen und erst dann wird die API gecallt.
Ich gebe dem API-Aufruf keine Pfadangaben zur DLL mit - es müsste also eigentlich versucht werden, die DLL aus dem SYstem32 Verzeichnis zu laden und nicht aus dem SYSWOW64 Verzeichnis. Da im SYSTEM32 Verzeichnis nur die 64Bit DLLs sind und ein 32Bit Programm die nicht laden kann, müsste das gewaltig in die Hose gehen.
Warum das wohl trotzdem funktioniert, sieht man hier: Suche dringend Leute mit 64Bit Betriebsystemen...
Zum Laden der DLL startet Windows7 zusätzliche Threads. Da Wow64DisableWow64FsRedirection sich nur auf den aktuellen Thread auswirkt, wird trotzdem die 32Bit DLL geladen, egal welchen Pfad man mitgiebt.
(Da ich das Verhalten von LoadLibrary ansonsten im Augenblick nicht nachvollziehen kann, ist das erst mal ein Erklärungsversuch von mir.)

Ob das auf anderen Systemen auch so ist - ist fraglich...

Ich könnte mir zum Beispiel vorstellen, das XP 64Bit oder Vista 64Bit das Testprogramm die Messagebox nicht bringt, sondern abstürzt.

[AHT]

Code zum Testen:

DEF GetModuleHandle(1) !"KERNEL32","GetModuleHandleA"
DEF GetProcAddress(2) !"KERNEL32","GetProcAddress"
Def GetModuleFileName(3) !"KERNEL32", "GetModuleFileNameA"
Declare API_ausfuehren&, Wow64EnableWow64FsRedirection&, Wow64DisableWow64FsRedirection&
Declare MHANDLE&, OldValue&, 64Bit&, MODULE$, Funktion$, HDLL&, FileName$
FileName$ = Space$(601)
Clear 64Bit&
Module$ = "Kernel32.DLL"
MHANDLE& = GetModuleHandle(ADDR(Module$))
Funktion$ = "Wow64DisableWow64FsRedirection"
Wow64DisableWow64FsRedirection& = GetProcAddress(MHANDLE&, ADDR(FUNKTION$))
Funktion$ = "Wow64EnableWow64FsRedirection"
Wow64EnableWow64FsRedirection& = GetProcAddress(MHANDLE&, ADDR(FUNKTION$))
Funktion$ = "IsWow64Process"
MHANDLE& = GetModuleHandle(ADDR(Module$))
IF GetProcAddress(MHANDLE&, ADDR(FUNKTION$))<>0
 External("Kernel32.dll", "IsWow64Process", External("Kernel32", "GetCurrentProcess"), Addr(64Bit&))
endif
CLS
'Umleitung deaktivieren
 IF (64Bit& = 1) : Set("FastMode", 1) : Call(Wow64DisableWow64FsRedirection&, addr(OldValue&)) : endif
HDLL& = UseDLL($SYSPATH + "\" + "Wintrust.DLL")
Print HDLL&
'Umleitung aktivieren
 IF (64Bit& = 1) : Call(Wow64EnableWow64FsRedirection&, addr(OldValue&)) : Set("FastMode", 0) : endif
GetModuleFileName(HDLL&, addr(FileName$), 600)
Print FileName$
FreeDll HDLL&
'Umleitung deaktivieren
 IF (64Bit& = 1) : Set("FastMode", 1) : Call(Wow64DisableWow64FsRedirection&, addr(OldValue&)) : endif
HDLL& = UseDLL("Wintrust")
Print HDLL&
'Umleitung aktivieren
 IF (64Bit& = 1) : Call(Wow64EnableWow64FsRedirection&, addr(OldValue&)) : Set("FastMode", 0) : endif
Print ""
GetModuleFileName(HDLL&, addr(FileName$), 600)
Print FileName$
Waitkey

Wie gesagt - DLL wird geladen, trotz deaktivierter Dateiumleitung.
Das schreibt Microsoft hier dazu:

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

Was ist nun? Die Umleitung ist doch deaktiviert (oder sehe ich da was falsch) und das Laden geht trotzdem....

[Sascha Oliver Haak]

@AHT

Hier nochmal kurz nachgelegt zwei Bilder aus meinem System

Bild 1 vor dem click
Bild 2 nach dem click

Hilft es Dir ?

Gruß
Sascha

[AHT]

Leider sieht man die Threads nicht, wenn man USEDLL alleine aufruft.
Interessant ist auch, was Microsoft dazu sagt (siehe oben).
Wenn ich es richtig sehe, ist das was in der MSDN Dokumentation steht genau das Gegenteil davon, was unter Windows7 passiert:
Wie gesagt - DLL wird geladen, trotz deaktivierter Dateiumleitung.
Das schreibt Microsoft hier dazu:

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

[p. specht]

Vorschlag an die Admins: Alle 64-bit Themen zusammenführen in einen eigenen Oberpunkt, mit Threads als Äste? Nurmalsofrag1 von 3...

[AHT]

Als Fazit rate ich es erst mal dringend ab, bei deaktivierter Umleitung irgendwelche API Aufrufe zu tätigen, auch wenn das funktioniert. Die DLLs für den API Aufruf sollten vor der Deaktivierung der Umleitung des Dateisystems geladen werden. Bei deaktivierter Umleitung dann die API über Call ansprechen, nicht über External oder eine vorher über Def definierte Funktion.
Im Prinzip also grenau an das halten, was Microsoft dort in der MSDN Dokumentation schreibt.

[AHT]

Nochmals Update: An einem durch LoadLibrary durchgeführten Multithreading liegt das ganze definitiv nicht - Microsoft scheint da was anders in LoadLibrary gefixt zu haben. Fragt sich nur, wann das passiert ist...