Separate execution without application domain

Yes, there has always been a one-for-one correspondence of process handles and process ids. Somehow Domains violate that rule. I have not explored what the OpenProcess Windows API function does when it is given a process id of a process with multiple domains in it. OpenProcess assumes there is only one process for a process handle.

I am tempted to say it is Microsoft shenanigans but when I look up shenanigans it seems to harsh. I do think however that it is Microsoft using confusing terminology. I just don't know if it is marketing people or technical people in Microsoft that decided use the exe extension for executable code that is so different from any other type of executable code except for possibly Java executable files.

It was late in the day when I posted my last reply.

Attached is a project with a modified version of what Vulpes posted. My directory structure is different from what Vulpes used so the path to the second application is different plus I used different names. This version shows a little more. First note that the process handle (Process.Handle) is different for the two applications. If however we use GetProcessId to get the process id for the handle then we get the same process id.

To continue what you were saying, Vulpes, I suggest it is more significant to say (if it is true) that you can't have more than one unmanaged exes in a process. Then we can proceed by making it clear that the relevant Microsoft documentation says nothing about exe files (correct?); it uses the term "assembly".

Until Microsoft releases a new version of Windows that supports managed code as the native format, "normal" exe files are exe files that are either unmanaged entirely or that begin execution as an unmanaged exe.

Well, it depends what you mean by an .exe :)

An application domain executes an assembly and it's possible for an assembly to have the .exe file extension. However, it's not a 'normal' .exe because it contains IL and metadata rather than native code.

Here's a quick example of two .NET exes running in different application domains within a single process:

// domaintester.cs 

using System;
using System.Diagnostics;

class Program
{
   static void Main()
   {
     AppDomain currentDomain = AppDomain.CurrentDomain;
     string procName = Process.GetCurrentProcess().ProcessName;

     if (currentDomain.IsDefaultAppDomain())
     {
         Console.WriteLine("Hello from the default domain in {0}", procName);
     } 

     AppDomain testDomain = AppDomain.CreateDomain("TestDomain");
     testDomain.ExecuteAssembly("testdomain.exe");
     Console.ReadKey();  
   }
}

// testdomain.cs

using System;
using System.Diagnostics;

class Program
{
   static void Main()
   {
     AppDomain currentDomain = AppDomain.CurrentDomain;

     string procName = Process.GetCurrentProcess().ProcessName;

     if (!currentDomain.IsDefaultAppDomain())
     {
         Console.WriteLine("Hello from {0} in {1}", currentDomain.FriendlyName, procName);
     } 
   }
}

When you build these two files to domaintester.exe and testdomain.exe respectively and then run the former, you should see the following output:

Hello from the default domain in domaintester
Hello from TestDomain in domaintester

Although you can have two (or more) .NET .exes running in the same process, Sam's probably right that you can't have more than one 'normal' .exe running within a single process.

Microsoft has a way of confusing us by explaining a lot of stuff but hiding some critical details where it is difficult to find. The thing I suspect they are hiding from us is what does an application domain execute. I can't find the answer to that and it is not important to me to find the answer, but I will be very surprised if it is possible to execute more than one exe file in a process. Am I wrong? Is there any possible way to violate the rule that there is always one exe file corresponding with each and every process?