.Net on x64

[amadmonk]

Hopefully this will help some folks.

By default, .Net assemblies are compiled in what is known as "platform neutral" fashion. This means that the assembly should run on an x86 machine or an x64 (64 bit) machine equally well. When you actually run the "platform neutral" process (assembly), the CLR (.Net runtime) chooses the "correct" architecture to bind to based upon your current architecture. Usually, this is harmless (and, indeed, beneficial) behavior, since it means you really don't need to know what platform you're on.

However, whenever you're doing p/invoke, things get more complicated, because the native OS is NOT architecture-neutral. For instance, while there's a 64 bit version of GetThreadContext() there is NO 64 bit port of the function GetThreadSelectorEntry(). Per MSDN: "GetThreadSelectorEntry is only functional on x86-based systems. For systems that are not x86-based, the function returns FALSE." What this means to you is that if you run an architecturally-neutral .Net assembly that p/invokes to GetThreadSelectorEntry() (critical for the "correct" way to get the fs segment base, which in turn is critical for WoW hacking) on x64, it will always fail and may leave you scratching your head.

There are two ways to fix this. If you control the source code (you DO control the source code, right?), you can just tweak the project target for your .Net project. If you're using the full version of VS, you can change targets in the project properties. On VC# Express, you have to tweak the csproj properties manually. Open up the .csproj file, and look for a block of XML that looks like this:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">

(this is your "Debug" target for "AnyCPU" -- note that "AnyCPU" in this case is just for show; it doesn't control the compilation settings; you can change it to x86 if you'd like, though).

At the end of this xml block (IE, before the closing "</PropertyGroup>"), add:

<PlatformTarget>x86</PlatformTarget>

Do this for both the "Release" and "Debug" targets, and reload your project. Then when you build, you'll be creating an architecture-specific (x86) assembly. Now things like GetThreadSelectorEntry() should start working properly again, and you no longer have to worry about pointer widths, and so on.

Another option, if you have a bit of compiled .Net code that is an .exe, is just to run the platform neutral ("AnyCPU") assembly in an x86 wrapper. This will force the CLR to load the AnyCPU assembly as x86.

Note that this doesn't actually require .Net. If you wanted to write a C/C++ app that was bound to x86, and use it to shell execute your .Net assembly, that would work too (and be more generally applicable). However, CreateProcess is annoying, so here's the .Net version.

FWIW, I use this to launch IronPython (a Python interpreter that's natively bound to .Net) as a 32-bit process for teh WoW hacking, without having to build separate architecture-bound versions of ipy.exe. Works a treat...

To do this, you'll need to compile a small .Net exe (as x86 -- see above!), and then when you launch the AnyCPU target, launch it through this wrapper exe. Instead of MyApp.exe, do RunAs32Bit.exe MyApp.exe.

Here's the source code to RunAs32Bit.exe. Remember, you MUST compile this as x86-targeted code for it to be of any use. See the above instructions for how to do this! The benefit of this method is you only have to do it once. The main drawback is that your target has to be an .exe.

using System;
using System.IO;

namespace RunAs32Bit
{
    class Program
    {
        static void ExitUsage(int exitCode)
        {
            Console.WriteLine("\nUSAGE: RunAs32Bit <dot_net_assemblyname>");
            Console.WriteLine("       Attempts to run the platform-neutral .Net assembly EXE");
            Console.WriteLine("       inside a 32-bit wrapper process (thus forcing the wrapped");
            Console.WriteLine("       assembly to be 32 bits.)  USE WITH CARE!\n");

            Environment.Exit(exitCode);
        }

        static void Main(string[] args)
        {
            if (args.Length == 0)
            {
                ExitUsage(1);
            }
            else
            {
                string fileName = args[0];
                if (!File.Exists(fileName))
                {
                    Console.WriteLine("Could not find file \"{0}\" fileName.", fileName);
                    ExitUsage(2);
                }

                string fullPath = Path.GetFullPath(fileName);
                string containingFolder = Path.GetDirectoryName(fullPath);
                if (String.IsNullOrEmpty(containingFolder))
                {
                    containingFolder = Path.GetPathRoot(fullPath);
                }

                AppDomainSetup setup = new AppDomainSetup();
                setup.ApplicationBase = containingFolder;
                setup.PrivateBinPath = containingFolder;

                AppDomain newAD = AppDomain.CreateDomain("WrapperDomain", null, setup);

                Console.WriteLine("-- Executing {0} as 32-bit wrapped assembly...", fullPath);
                newAD.ExecuteAssembly(fullPath);
            }
        }
    }
}

The moral of this story is that just because .Net abstracts you away from the "metal" (the actual processor achitecture), that doesn't mean it's always a good thing.

[Apoc]

Instead of editing the project files, VS allows you to set the preferred architecture straight from the IDE. (As well as a slew of other things.)

Just check the properties for the project/solution.

[amadmonk]

Sadly, the Express edition doesn't let you manually choose any target besides "AnyCPU"... one of the lovely little limitations built in by Microsoft to point you towards the full version.

/platform (Specify Output Platform) (C#)

Note /platform is not available in the development environment in Visual C# Express.

For information on how to set this compiler option programmatically, see PlatformTarget.

[Apoc]

Another reason why I don't use VS Express.

Just be like the rest of the internet population, pirate it.

[amadmonk]

It's odd... I used to work on the Visual Studio team. Maybe it's some misplaced sense of loyalty?

But mostly I use Express because it does almost everything that the full version does, and it's waaaaaaaaaaaay less bloated. There are a few annoyances, tho...