wow64 | 易学教程

WOW64 Redirection and LoadLibrary

阅读更多关于 WOW64 Redirection and LoadLibrary

问题 I'm trying to build a 32-bit program that can run correctly on 64-bit Windows; that is, if it needs to open a text file for the user, the file needs to not be redirected from C:\Program Files to C:\Program Files (x86) . However, if I just call Wow64DisableWow64FsRedirection , then my program fails to load at all because some system libraries call LoadLibrary when portions of the GUI are loading, which tries to load a 64-bit version of a system DLL into my program. How do I solve this problem?

Running 32 bit apps in WinPE 3 (Win7) 64 bit

阅读更多关于 Running 32 bit apps in WinPE 3 (Win7) 64 bit

问题 Trying to run any 32 bit app in the WinPE 3.0 (Win7) 64 bit environment will result in the following error message: The subsystem needed to support the image type is not present. The missing subsystem in question is Windows on Windows 64 (WOW64): the compatibility layer allowing 32 bit apps to run in the 64 bit OS. The question is: would it be possible to install WOW64 in WinPE? If so, how, and how big is the set of files to be installed? Thank you. 回答1: Unfortunately this doens't really

32-bit OpenFileDialog --> 64-bit System32?

阅读更多关于 32-bit OpenFileDialog --> 64-bit System32?

问题 In a 32-bit program, how can I get the Open/Save File Dialogs to show the files in the System32 folder of a 64-bit system? ( Wow64DisableWow64FsRedirection doesn't work, because for some reason it doesn't work for the dialog, I'm guessing because it's on a different thread. And of course using SysNative doesn't work because the user isn't aware of what's going on internally; he just wants to see the "actual" files on the computer.) Here's another way to ask the question: Does any 32-bit

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId not found running 32bit app on 64bit Windows

阅读更多关于 HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId not found running 32bit app on 64bit Windows

问题 As title really. Looking in regedit the key-value exists, but the Wow6432 key (HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion) doesn't have this key. This means a 32-bit app doesn't work on my 64-bit Windows version... which seems wrong, shouldn't the 32-bit app run without modifications? Or is this one case 32-bit apps have to be tweaked to work on 64bit Windows? 回答1: Applications really shouldn't access this registry value directly. The best way to get this value is to use

PostMessage params from 32-bit C# to 64-bit C++

阅读更多关于 PostMessage params from 32-bit C# to 64-bit C++

问题 I am having problem with the contents of a pointer passed as the wParam from a 32-bit C# application is changing along the way to a 64-bit C++ process. There are two processes 32.exe (in C#) and 64.exe (in C++). 64.exe is started as a child process of 32.exe. 32.exe post window message for 64.exe, one of which has a wParam that is a pointer to an array of RECT structures. Both 64.exe and 32.exe have a common DLL (written in C++, but compiled for different platforms, of course), called 32.dll

SuspendThread WOW64 suspending in kernel code

阅读更多关于 SuspendThread WOW64 suspending in kernel code

问题 UPDATE : Microsoft have yet to fix it in Windows 8.1. EDIT : This turned out to be a bug in WOW64 - GetThreadContext() may return stale contents when the thread is suspended in long mode ring-3 (user mode). I've suggested to Microsoft to use ring-2 to perform the translation. SuspendThread would then only suspend thread in ring-3 (as it does now - no changes necessary), and a crash/fault/exploit in ring-2 won't affect the kernel - it'd only affect ring-2 and ring-3. Such changes would

Scanning process memory causes crash

阅读更多关于 Scanning process memory causes crash

问题 i have injected my DLL into process and i try to scan memory for addresses with same value as mine, but it results in a crash after i get 1st address , it should be 10 addresses for(DWORD i = MEM_START; i< MEM_END ;i++) { VirtualQuery((void*)i,pMemInfo,sizeof(MEMORY_BASIC_INFORMATION)); if(pMemInfo->AllocationProtect == PAGE_READONLY || PAGE_EXECUTE_WRITECOPY || PAGE_READWRITE || PAGE_WRITECOMBINE) { if(*(DWORD*)i==1337) { addresses.push_back(i); } } } I believe my protection check is wrong

Do 32 bit programs run relatively slower on 64 bit OS against when they are natively run in 32 bit OS [closed]

阅读更多关于 Do 32 bit programs run relatively slower on 64 bit OS against when they are natively run in 32 bit OS [closed]

Closed. This question is off-topic . It is not currently accepting answers. Want to improve this question? Update the question so it's on-topic for Stack Overflow. Closed 8 years ago . I was reading about WOW 64 here http://en.wikipedia.org/wiki/WOW64 and learnt that its a layer in 64 bit Windows OS to run 32 bit programs. So can I assume that 32 bit programs run relatively slower on 64 bit OS against when they are natively run in 32 bit OS. I can see the advantages of memory access of over 4 GB in 64 bit OS. But does this advantage necessarily offset the small overhead added by layer of WOW64

WOW64 woes (.lnk shortcuts)

阅读更多关于 WOW64 woes (.lnk shortcuts)

I'm using Windows 7 (x64) and Delphi 2010. I'm writing a component that will emulate the start menu. However, I've run into the following problems: If I attempt to open a shortcut (.lnk file) with ShellExecute , this will fail whenever %ProgramFiles% is part of the target path of the shortcut (it will then look at the C:\Program Files (x86) folder instead of C:\Program Files ); ShGetFileInfo fails to extract the correct index of the icon in the system image list if %ProgramFiles% is part of the path to the icon file (same problem as above). Is there any workaround to the above issues or do I

SuspendThread WOW64 suspending in kernel code

阅读更多关于 SuspendThread WOW64 suspending in kernel code

UPDATE : Microsoft have yet to fix it in Windows 8.1. EDIT : This turned out to be a bug in WOW64 - GetThreadContext() may return stale contents when the thread is suspended in long mode ring-3 (user mode). I've suggested to Microsoft to use ring-2 to perform the translation. SuspendThread would then only suspend thread in ring-3 (as it does now - no changes necessary), and a crash/fault/exploit in ring-2 won't affect the kernel - it'd only affect ring-2 and ring-3. Such changes would necessitate the change of a few WinAPI functions such as Wow64Get/SetThreadContext etc. This would break apps