如何将同代码的32位与64位全局钩子应用合并为单EXE？

Absolutely, you can combine your two identical-code 32-bit and 64-bit global hook EXEs into one single executable that handles both architectures. Here’s how to do it using Visual Studio and other tools, tailored to your global hook scenario:

Option 1: Build a "Launcher" EXE with Visual Studio #

This is the most straightforward approach—create a small wrapper EXE that embeds both your 32-bit and 64-bit hook binaries, then detects the system architecture at runtime and launches the appropriate version.

Steps: #

1. Create the Launcher Project:
   • Open Visual Studio and create a new project (C# WinForms/Console or C++ Win32 Project works best). This will be your single "master" EXE.
2. Embed Hook EXEs as Resources:
   • For C#: Right-click your launcher project → Add → Existing Item, select your 32-bit and 64-bit hook EXEs. Then, in the Properties window for each EXE, set Build Action to Embedded Resource.
   • For C++: Add the EXEs to your project’s resource file (create one if you don’t have it) as custom resources (e.g., name them HOOK_32 and HOOK_64 with type EXE).
3. Add Runtime Detection Logic:
   • Write code to check if the system is 32-bit or 64-bit, then extract the corresponding embedded EXE to a temporary directory and launch it.
   • Example C# snippet:

     using System;
     using System.IO;
     using System.Reflection;
     using System.Diagnostics;
     
     namespace HookLauncher
     {
         class Program
         {
             static void Main(string[] args)
             {
                 bool is64BitOS = Environment.Is64BitOperatingSystem;
                 string tempExePath = Path.Combine(Path.GetTempPath(), is64BitOS ? "GlobalHook64.exe" : "GlobalHook32.exe");
                 string resourceName = is64BitOS ? "HookLauncher.GlobalHook64.exe" : "HookLauncher.GlobalHook32.exe";
     
                 // Extract embedded EXE to temp folder
                 using (Stream resourceStream = Assembly.GetExecutingAssembly().GetManifestResourceStream(resourceName))
                 using (FileStream fileStream = new FileStream(tempExePath, FileMode.Create))
                 {
                     resourceStream.CopyTo(fileStream);
                 }
     
                 // Launch the appropriate hook EXE
                 ProcessStartInfo startInfo = new ProcessStartInfo(tempExePath)
                 {
                     UseShellExecute = true,
                     WindowStyle = ProcessWindowStyle.Hidden // Adjust based on your needs
                 };
                 Process.Start(startInfo);
     
                 // Optional: Clean up temp file after launch (ensure the hook EXE is independent first)
                 // File.Delete(tempExePath);
             }
         }
     }
     

4. Compile and Test:
   • Set your launcher project’s target platform to Any CPU (for C#) or build for both architectures (for C++, but Any CPU simplifies things). When run on a 32-bit system, it’ll launch your 32-bit hook; on 64-bit, it’ll launch the 64-bit version.

Option 2: Use Third-Party "Fat Binary" Tools #

If you don’t want to write a custom launcher, you can use tools that merge multiple architecture binaries into one self-contained EXE:

• 7-Zip SFX: Package both your 32-bit and 64-bit EXEs into a self-extracting archive, then configure the SFX script to detect the OS architecture and run the correct EXE automatically.
• Resource Hacker: Manually add one EXE as a resource to the other, then use a small wrapper function (similar to the VS launcher) to extract and run it.

Critical Notes for Global Hooks #

Since you’re working with global hooks, keep these in mind:

• Cross-Architecture Injection: A 64-bit EXE can only inject 64-bit processes, and a 32-bit EXE can only inject 32-bit processes. The launcher approach ensures you cover both cases by running the matching architecture hook EXE.
• IPC Communication: If your launcher needs to interact with the hook EXEs, use inter-process communication (IPC) like named pipes, WM_COPYDATA, or shared memory.
• Digital Signing: If your original EXEs are signed, you’ll need to re-sign the merged launcher EXE to maintain trust.

内容的提问来源于stack exchange，提问作者Wolverine