Running applications under isolation can solve many problems; the registry and file system no longer conflict with other applications.  Great.  What does it really mean to run an application isolated?  This post will bring some clarity and also provide insight into how the Application Streaming isolation system works. 

Let's start with the definition of a sandbox.  Call it a sandbox, call it a bubble, call it an isolation space, its all pretty much the same goal.  How can I run an application without it doing things that I don't want it to do.  How can I let that application do ANYTHING it wants to do, but have its bad behavior not really occur?  Answer: I let the application play and do anything it wants so long as it doesn't leave the isolation sandbox.  Play, play, but so long as you don't leave the confines of the sandbox, I know you're pretty safe.

Operating system theory 101:  What is a process?

A process is an entity that holds things associated with running some program.  Generally, this is a holder for allocated memory and allocated threads.  Memory is pretty easy.  A thread is a something that the operating system knows how to "run".  In more techno jargon, a thread is something that can be scheduled to run on the CPU.  A single process commonly has multiple threads and each thread can allocate memory.  Since the memory is technically tied to the PROCESS rather than the thread, all threads in that process can see any memory allocated by any of the threads.   Okay, booring - I know all that already.

What is a sandbox?

A sandbox is a layer of abstraction on top of a process.  A Sandbox is a collection of processes and a set of RULES which control what the kids are allowed to do in the sandbox.  Example, digging, okay.  Dumping your drink into the sand, okay, the carpet inside the home is safe.  Hitting your brother in the ear with a rock, NOT okay.  Oh wait, wrong sandbox.

A sandbox is the thing that the isolation space uses to keep track of all the ISOLATED processes on the machine.  We over-dramatize this.  An isolated process is just like a normal processes, except is isn't generally allowed out of the sandbox.  Put your file system programmer hat on for a moment.  A disk operation comes wondering by your code and this is the place were you do isolation stuff.  What do you do with this operation?

Questions you ask yourself:  Do I care about this disk operation?  The answer is almost always no.   How to decide?  Answer: Process ID.  Conveniently, it is a "given" with all disk activity.  Filtering code looks up the process ID in its list of sandboxes (an in memory B-Tree if anyone wants particulars).  Most of the time, none found and the disk operation proceeds along its merry way without being messed with.  Occasionally though - and always for the isolated process - the disk filter says WOW!  I got a live one and goes to work.  With a hit, it knows which "sandbox" this process is part of and with that, it knows what isolation rules govern the operation of this disk operation.  Notice that threads are not part of the equation.  It is the process membership that governs isolation.

What is a "rule"?

On receiving a disk operation that it wants to filter - the filtering code has to decide what to do with it.  Which isolation rule should be applied.  Here, the file/path or registry key/item is looked up in a list of rules that are part of the sandbox (more in memory B-Trees).   Eventually, the code identifies the "deepest" rule that effects this thing and then uses that to complete the disk/registry operation.  Technically, the isolation code doesn't complete anything, it just modifies the original file/reg request and sends it back down the path to work on places other than where it was to work before.

What kinds of rules are there?  

Isolate - They wanted to mess with Windows; instead have them mess with VerySafePlaceWindows.   Stay in the BOX!

Ignore - They wanted to mess with %TMP%.  I don't really care what they do to %TMP%.  Push it on with no modification.

Redirect - They wanted to mess with "Documents and settings", instead send them to Users.  Oh, wait, that's Vista.  Same stuff.

Strictly isolate - Clearly the neatest of all the rules. 

The Strictly Isolate rules are new to Application Streaming - didn't exist in AIE.  The application wanted to mess with "Program FilesCo NameApp name" and that directory didn't exist at time profiling started, so from the view of the application at runtime, the only content that directory has is the stuff that the installation program added during profiling.  In the layers of glass analogy, the bottom layer (the physical layer) disappears.  These are added authomatically by the Streaming Profiler during that "finalizing your profile" step.  As the admin, you can add them too though this usually is not needed if the profiling machine was relatively clean at the start.

EVERYTHING ABOVE HAPPENS FOR THE REGISTRY TOO

Registry is a bit easier though - or harder - depends how you look at it.  The registrying hooking is all done at application level and here, the isolation system is only involved with isolated processes and always "knows" which set of rules effect it.  It is PART OF the isolated process, so looking things up is a given.

Who are your ancestors?

Among the neater things of managing sandboxes is keeping track of the process list.  Everyone is used to the idea that launching an application creates a process; what they are not used to is that the started process starts other processes; kills itself; the children then mingle with other processes and start new ones and they then wonder around the machine and try to get into trouble.  Managing the sandbox says that everyone in your ancestory tree is part of the sandbox and people who are members of the family are not allowed to leave just because they get pissed off at the processes next to them.

The part that makes this cool is that the Windows APIs that tell you about process "launch" and "terminate" tell you about the immediate parent - and that's it.  Once the parent dies, all history of who that parent was is gone!  It is up to the isolation code to keep track of the grandparents who may or may not be alive anymore and since they have cousins and since the cousins are part of the family, they are all part of the same isolation sandbox.

One of the very first things I did when the Application Streaming team took over the AIE code from Presentation Server 4.0 to use as the basis of Rade, was try to BREAK the process logic.  To my happiness - it was bullet proof.

Eventually, all of the processes that are part of the sandbox terminate - when they do, the isolation system declares the sandbox dead and starts tearing it down.  This is where post-exit scripts kick in and licenses are released. 

WHAT IS THE POINT OF THIS POST?

Isolated processes are just like regular processes.  Actually, they are regular processes, they just get "filtered" a bit as they execute.  Everything CPU wise happens "native speed" and everything about memory usage and other "process" things are same for isolated processes as they are for native processes.  A process is a process is a processs.