App-V 1703 Virtual Registry and Containers?
One of the things I talked about when App-V was going into the core of the OS was how it was going to provide new opportunities to improve App-V. And the prime example I gave was how the virtual registry worked. Well I was eventually proved right, although the transition is proving to be a bit bumpy for some folks (more on that later).
When we built SoftGrid, the original name for App-V, we kept the virtual registry out of the real-windows registry. This was done by redirecting the registry reads and writes to our own driver software that worked using files external to the registry. In some of the App-V 4.x performance testing I did back in the day I was able to show how under certain (specially concocted) circumstances, App-V could actually improve an app’s performance when virtualized over the native performance because this file access was better than that of the actual registry on older OSs.
When Microsoft re-wrote the software for 5.0, they wanted to eliminate undocumented file formats and turn to modern standards, so they integrated the virtual registry directly into the real thing. But because at that time they were not part of Windows core, the dev team was limited to the same APIs that external developers have access to. (This was due to rules implemented when the US government and Microsoft settled the anti-trust suit that threatened to break up an alleged Microsoft monopoly). Which meant that when they wanted to mount a new package’s virtual directory they had to do the equivalent of a registry import — one item at a time. They called this registry staging and tried to hide it in the background, but it still was a significant performance impact to non-persistent logons.
Read the entire article here, App-V 1703 Virtual Registry and Containers?
Via the fine folks at FSLogix/a>.