如何让在64位Windows的32位应用程序,以执行在Windows \ System32下提供64位应用程序应用程序、Windows

2023-09-09 21:14:59 作者:北方没有你

假设你有一个应用程序,要为用户提供浏览system32目录和执行程序(如远程登录)的能力。

什么是支撑这个时候,你需要支持XP开始为客户机和2K起服务器的最佳方法是什么?

已经写了这一切了,我不知道,如果它只是太多的时间/精力在提供浏览做到这一点,在那里他们可以只从资源管理器中复制。仍然需要启动的能力。的

我已经找到了一些讨论 Nynaeve 。

到目前为止,似乎有下列选项

在窗口,这将允许您浏览/执行64位创建sysnative文件夹。问题是: 仅在Vista中/ Longhorn中提供,所以对于XP 64 不支持 导致不同的路径命名,不能在多个版本使用相同的路径。 将激活整个窗口的,不只是我们的应用程序 不可以(可能不是)适合安装应用程序时做 允许通过路径明确指定仅该应用程序的版本,推出,如果有一个32位和64位版本 使用Windows API来暂时禁用重定向显示文件列表或执行用户运行命令时。问题是: 仅适用于64位 - 必须惹GetProcAddress的 仅在特定的服务包提供 必须单独标识的所有位置,这应该执行 在用户将需要提供有关这是否是一个64位应用程序或32位单独的信息。

如果任何人有这显示Windows打开文件对话框(比如使用MFC的CFileDialog),显示nativly为XP / Vista和允许64位system32目录下的观看一些例子code,这将是真棒。

如果任何人有发动命名的应用程序的例子,这也将是伟大的!

编辑: 目前我们使用的CreateProcess用于启动应用程序(这是失败的)。

  ERR =的CreateProcess((wchar_t的*)exeName.c_str(),(wchar_t的*)cmdLine.c_str(),NULL,NULL,FALSE,CREATE_SEPARATE_WOW_VDM,NULL,workingDir.c_str( ),安培; STARTUPINFO,&安培; processInfo);
 
现在运行的是Windows7 32位系统,想再装上个64位的行吗,其能自己调用吗

解决方案

我已经使用选项2, 对于那些谁可能会感兴趣;这里是我快速的黑客在管理WOW64重定向的基础上从MS笔记禁止的范围内的版本。将重定向如果API可用,预计KERNEL32.DLL已经可用。

 类Wow64RedirectOff {
    的typedef BOOL(WINAPI * FN_Wow64DisableWow64FsRedirection)(__out PVOID *的OldValue);
    的typedef BOOL(WINAPI * FN_Wow64RevertWow64FsRedirection)(一切变得PVOID的OldValue);

上市:
    Wow64RedirectOff(){
    LPFN_Disable =(FN_Wow64DisableWow64FsRedirection)GetProcAddress的(
    的GetModuleHandle(TEXT(KERNEL32)),Wow64DisableWow64FsRedirection);
    如果(LPFN_Disable){
    LPFN_Disable(安培;的OldValue);
    }
    }

    〜Wow64RedirectOff(){
    如果(LPFN_Disable){
    FN_Wow64RevertWow64FsRedirection LPFN_Revert =(FN_Wow64RevertWow64FsRedirection)GetProcAddress的(
    的GetModuleHandle(TEXT(KERNEL32)),Wow64RevertWow64FsRedirection);
    如果(LPFN_Revert){
    LPFN_Revert(的OldValue);
    }
    }
    }

私人:
    FN_Wow64DisableWow64FsRedirection LPFN_Disable;
    PVOID的OldValue;
};
 

和这样的用法是

  Wow64RedirectOff scopedRedirect;
// CFileOpen
// CreateProcess的
 

Say you have an app, that you want to provide users ability to browse the system32 directory and execute programs in (like telnet).

What is the best method for supporting this when you need to support XP onwards as a client and 2k onwards for server?

Having written all this up I wonder if it's just too much time/effort in providing a browse to do this, where they could just copy it from explorer. Still requires ability to launch.

I have found some discussion on Nynaeve.

So far it seems there are the following options

Create a sysnative folder in windows which will allow you to browse/execute 64 bit. Issues are: only available in Vista/Longhorn, so no support for XP 64 leads to different path naming, can't use same path on multiple versions. will be active for whole of windows, not just our app may not (probably is not) appropriate to do when installing the app allows to specify explicitly through path only which version of the app to launch if there is a 32 bit and 64 bit version Use the windows API to temporarily disable the redirection when showing file lists or executing users run commands. Issues are: Only available on 64 bit - have to mess with GetProcAddress available only under certain service packs must individually identify all locations that this should be implemented user will need to provide seperate information about whether this is a 64 bit app or 32 bit.

If anybody had some example code which displayed a Windows OpenFile dialog (say using MFC CFileDialog) showing nativly for XP/Vista and allowing the viewing of 64 bit system32 directory, that would be awesome.

If anybody had an example of launching the named app, that would also be great!

Edit: Currently we use CreateProcess for launching the app (which is failing).

err = CreateProcess((wchar_t*)exeName.c_str(), (wchar_t*)cmdLine.c_str(), NULL, NULL, FALSE, CREATE_SEPARATE_WOW_VDM, NULL, workingDir.c_str(), &startupInfo, &processInfo);

解决方案

I've gone with option 2, For those who might be interested; here is my quick hack at a scoped version of managing the disabling of Wow64 redirection based on notes from MS. Will redirect if the API is available, expects that kernel32.dll is already available.

class Wow64RedirectOff {
    typedef BOOL (WINAPI *FN_Wow64DisableWow64FsRedirection) ( __out PVOID *OldValue );
    typedef BOOL (WINAPI *FN_Wow64RevertWow64FsRedirection) ( __in  PVOID OldValue );

public:
    Wow64RedirectOff() {
    	LPFN_Disable = (FN_Wow64DisableWow64FsRedirection)GetProcAddress(
    		GetModuleHandle(TEXT("kernel32")),"Wow64DisableWow64FsRedirection");
    	if( LPFN_Disable ) {
    		LPFN_Disable(&OldValue);
    	}
    }

    ~Wow64RedirectOff() {
    	if( LPFN_Disable ) {
    		FN_Wow64RevertWow64FsRedirection LPFN_Revert = (FN_Wow64RevertWow64FsRedirection)GetProcAddress(
    			GetModuleHandle(TEXT("kernel32")),"Wow64RevertWow64FsRedirection");
    		if( LPFN_Revert ) {
    			LPFN_Revert(OldValue);
    		}
    	}
    }

private:
    FN_Wow64DisableWow64FsRedirection LPFN_Disable;
    PVOID OldValue;	
};

And thus usage would be

Wow64RedirectOff scopedRedirect;
//CFileOpen
//CreateProcess