Prozedureinsprungpunkt "Wow64RevertWow64FsRedirection" wurde in DLL "KERNEL32.dll" nicht gefunden

[Red Skall]

Die Anwendung läuft unter Windows 7. Unter Windows XP (SP3) erscheint die genannte Fehlermeldung. Unter Windows 2000 habe ich erst gar nicht probiert ob die Anwendung funktioniert.

Schön wäre wenn die Anwendung wenigstens unter Windows XP laufen würde.

Die Fehlermeldung erscheint sofort beim Ausführen der Applikation - es wurde noch nicht einmal der Konstruktor meiner CWinAppEx-SubClass aufgerufen! Ich kann also nichtmal nachvollziehen wo das Problem auftaucht.

Gruß,
Marco

[Techel]

Die funktion gibts nur unter 64 bit, der Loader von Windows kann die Funktion beim laden der dlls also auch nicht finden. Die Funktionsadresse sollte also manuell mit GetProcAddress gefunden werden.

[Martin Richter]

Welche VS Version wurde verwendet?
Hast Du das entsprechende Toolset für XP eingestellt. Sonst geht das mit neueren Studio Versionen gar nicht.

Ansonsten: Vergiss XP einfach.

[Red Skall]

Ich hatte bisher Visual Studio 2010 verwendet.

Jetzt habe ich es mit Visual Studio 2008 und dem FeaturePack probiert:
Den Code konnte ich problemlos kompilieren, aber es erscheint genau der selbe Fehler..

XP ist leider wichtig für das Projekt.

[Techel]

Wie gesagt.

[hustbaer]

roflo schrieb:

Die funktion gibts nur unter 64 bit

Nö, die Funktion gibt's bloss im 32 bittigen Windows XP nicht. In späteren Windows Versionen gibt's die auch in der 32 Bit Version.

@Red Skall
Wie Martin Richter schon geschrieben hat musst du bei neueren Visual Studio Versionen das Toolset umstellen.
Ansonsten würde ich mal gucken wo die Dependency überhaupt herkommt. Könnte ja sein dass die gar nicht von der CRT/MFC kommt, sondern von einer anderen LIB bzw. DLL die das Projekt verwendet.

Wenn die Dependency aus einer DLL kommt, kannst du das schön mit Dependency-Viewer sehen (gratis Tool, sehr praktisch).
Wenn die Dependency direkt in der .EXE ist, wird es etwas lästiger rauszubekommen wo sie herkommt.

Ansonsten... auf jeden Fall das aktuellste Update für VS installieren. Bei VS 2012 gab's z.B. Versionen wo die XP Toolchain "defekt" war - also Programme generiert hat die halt doch nicht so ganz XP-kompatibel waren. Bezüglich VS 2010 bzw. 2008 kann ich mich da zwar an nix erinner, aber das aktuellste Update solltest du mMn. sowieso installiert haben.

[Red Skall]

In den Projekteinstellungen steht die Toolwert-Version "110_xp" nicht zur Verfügung, auch nicht nach dem Update 4 für Visual Studio..
Nebenbei: Das Update 4 enthält doch auch alle vorherigen Updates (1, 2, 3) oder?

Aber wenn ich das Programmunter Visual Studio 2008 kompiliere, kommt es dann nicht aufs Gleiche raus!?

[hustbaer]

Red Skall schrieb:

Das Update 4 enthält doch auch alle vorherigen Updates (1, 2, 3) oder?

Soweit ich weiss schon, ja.

Red Skall schrieb:

Aber wenn ich das Programmunter Visual Studio 2008 kompiliere, kommt es dann nicht aufs Gleiche raus!?

Aufs Gleiche kann man nicht sagen. Aber unter XP sollte der Output vom 2008er Studio noch laufen, ja.

[Red Skall]

Hab mit dem Dependency Walker mal reingeschaut, vermute dass die Dependency aus der .exe Datei kommt.

Für die DLLs, die ich importiert habe, werden keine fehlerhaften dependencies angezeigt.

Aber es gibt nicht aufgelöste C Funktionen in 2 DLLs:
"Kernel32.dll"
- Wow64DisableWow64FsRedirection
- Wow64RevertWow64FsRedirection
"WS2_32.dll"
- inet_pton

Wenn die nicht aufgelösten C Funktionen aus meiner Anwendung stammen würden, würde mir das der Dependency Walker durch das Symbol vor meiner .exe Datei anzeigen, richtig?

[Gast]

Ich hatte bisher Visual Studio 2010 verwendet.

Damit habe ich unter XP (und ebenso unter Win 7) problemlos 32 bzw. 64Bit Versionen ein und derselben Software erstellt - für XP und Windows 7.
Kann es sein, dass Du einfach nur die libs der falschen Plattform eingebunden hast (also die der 32Bit unter 64 oder umgekehrt)?

[Gast]

Aber unter XP sollte der Output vom 2008er Studio noch laufen,

und auch das des 2010er mit dem entsprechenden vcredist.

[Red Skall]

So, ich kann jetzt auch alles unter WinXP ausführen

Es lag an der statischen Einbindung der DLL-Funktionen und es ist auch nachvollziehbar dass es nicht geklappt hat.

Mir war der Zusammenhang nicht klar, dass die Links auf tatisch gelinkte DLL-Funktionen nicht erst bei Funktionsaufruf passiert, sondern schon wenn die Anwendung geladen wird.

Ich linke jetzt dynamisch und wenn eine Funktion nicht existiert muss ich entsprechend reagieren.

Gruß und vielen Dank!