They are very different.  Virtual PC is virtual machine software, i.e.
you have a complete virtual computer in which you install a full OS
that runs independently of the host OS, but as an application

I have used both extensively and I find SVS useful but it solves an entirely
different class of problems than Virtual PC. To put it simply, Virtual PC
virtualizes the entire PC down to the operating system, BIOS, and hardware.
SVS virtualizes individual application programs within the 32-bit Windows
environment. If you happen to be dealing only with 32-bit Windows
applications which are truly normal applications (meaning user mode code
only, no kernel mode device drivers involved) then you can sometimes
accomplish similar goals with SVS as with Virtual PC, and the SVS approach
will usually perform better in terms of speed, memory usage, and disk usage.
However, SVS does not offer the degree of isolation and protection that
Virtual PC does. When you create a "layer" in SVS terminology, it captures
the file system changes and registry changes that an application's installer
makes, and these changes only exist when the layer is "activated." You can
"reset" the layer to flush any writes to the layer which occur after the
initial creation. In theory, this makes the layer self-contained and
independent of the host system. For example, if a common shared DLL gets
corrupted on your host by some other application, the layer could have its
own copy which remains a known good version. You could also export the layer
to a *.vsa file and transport it to another host.

The flaw in this scheme is that many (not all, but many) application
installers don't always write every file and registry change that they many
need. Often, they will skip any pieces which already exist on the system at
the time of install, and they don't always go through the proper APIs when
checking for the existence/version of those pieces, so it is impossible for
SVS to detect these situations. This means that a layer CAN become broken
due to changes which occur in the host environment, and a given layer may or
may not be portable between any two given systems. There is an "Advanced
Editor" within the SVS Admin Console which lets you manually fix the layer
IF you know exactly what an application needs which SVS was unable to
detect, but this kind of stuff will often be rocket science to most users.
This is one of the reasons that Altiris maintains a wiki documenting
app-specific details, as well as a library of pre-built *.vsa files for
popular apps. By virtualizing the entire environment, Virtual PC eliminates
the need for end-users to identify and understand all the little details
which could affect an app under various conditions, and the tradeoff comes
down to *.vhd files frequently measured in gigabytes versus *.vsa files
frequently measured in megabytes.