How SVS Uses Process IDs to Determine Where Changes Should Go

SVS keeps track of process IDs and uses that information to determine where file and registry changes should be stored -- (in a layer or in the base). Jared Payne explains the rules SVS uses to make these decisions.

SVS keeps track of process IDs and uses that information to determine where file and registry changes should go. When a process starts, SVS looks to see where the exe file exists. If the exe file is coming from a layer, that layer is said to be the "owner layer" for the process. When that process makes a file or registry request, preference is given to the data in that layer.

Here are the rules SVS uses to determine if a process has an owner layer and which layer that is:

1. If the exe file that is being used to create the process is in a layer, that layer is the "owner layer".
2. If rule 1 does not apply and the parent process has an "owner layer", the new process has the same "owner layer".

This can be complicated some times when "interpreted" programs are run. For example, if you have a java application in one layer and the JVM (Java Virtual Machine) in another layer, where do the changes go? This can apply to any program that needs a separate interpreter to run; like Python, Perl, or Ruby. Usually when an interpreted application runs, a child process is spawned that does all the work. Understanding how child processes are associated is critical to getting the results you want.

For example, let's look at Java and Eclipse. Eclipse is a Java application. When eclipse.exe runs it spawns javaw.exe as a child process. javaw.exe is the process that actually does all the work; not eclipse.exe.

Java Installed on the base, Eclipse installed on the base.
Java and Eclipse act just like it normal.

Java installed in a layer, Eclipse installed in layer.
Everything goes to the Java layer. Rule1.

Java installed in a layer, Eclipse installed on the base
Everything goes to the Java layer. Rule 1.

Java Installed on the base, Eclipse installed in a layer.
Everything goes to the eclipse layer. Rule 2.

Java and Eclipse Installed in the same layer.
Everything will go to the unified layer. Rule 1. Packaging Java and the application in the same layer assures that the correct JVM is running. Watch out for the case where another Java app uses the JVM in the unified layer. Changes will go into the layer, not the base.

16 bit Applications
16-bit applications do not run natively in Windows. These applications are run by a virtual machine who's executable is ntvdm.exe. If you execute a 16-bit application, Windows detects the 16-bit mode and passes the application's executable to ntvdm.exe which then executes the program. Since Windows started ntvdm.exe, ntvdm.exe is associated with the base. This means your 16-bit applications do work but they will run as if from the base.