What I'd like from future Windows (isolated installs with state merging & updates)

A particular reason I don't like using VM's has to do with that I tend to make many snapshots with different "tasks". The primary reason for using VM's is installing stuff that may mess around with the OS and other installed apps, so obviously, for each thing I have different snapshot. Also these "tasks" or apps in my testing often do not work with application virtualization, atleast not without spending bunch of time tweaking it - and the perf can suffer.

Then comes the problem of Windows Updates. If I have to update those invidually into each snapshot this will waste both time going through the snapshots manually and disk space by downloading the updates into each snapsot, which have tasks going on that I don't want to close down or reboot.

So, what I'd like is:

1) Ability to install apps with full isolation to Windows without using VM with separately installed Windows guest. This just means that whatever changes the app makes to disk or registry, will only be seen by that app.

The isolated app should be able to install and use whatever drivers it pleases, but these drivers will not see anything beyond a clean windows install unless user either merges state or chooses to expose something (eg. shared folder) to the isolated install.

2) Ability to merge the isolated apps changes either into other isolated apps (two isolated states become one) or into the OS (remove isolation and the app sees everything as normal app would)

3) Ability to a) Suspend all the processes and threads related to the isolated app, b) apply the most critical Windows updates to all memory and files, isolated or not, without reboot and c) resume.

edit: yeah I do realize the Metro apps kinda sorta enable this. So, maybe in few decades this will be true, assuming every app will have a Metro version...

IMO, you can always have a master VHD image that contains system and commonly used programs, then put your development tools and such in a secondary VHD. With ProcMon and "Undo disk" feature of VM, you can extract the list of registry values/files installing on the system, so you can put them in seperate folder and got them patched to the system on "System Start" schedule.

Requires lots of work on your behalf, but certainly could be done.

======

Regarding drivers... could you even be sure that the "isolation" related system service are loaded when the driver is loading? I believe the current isolation model is depending on winlogon, but by the time it's loaded it could be too late for certain drivers...

Also, from documentation it seems driver's Unload() is not required to be implemented except for WDM drivers.

The isolated app should be able to install and use whatever drivers it pleases, but these drivers will not see anything beyond a clean windows install unless user either merges state or chooses to expose something (eg. shared folder) to the isolated install.

Drivers run in ring zero, so you can't hide stuff from them without being a full VM. If they want to open up your disk or network and write raw sectors or packets there's nothing you can do to stop them.

If you're talking about just normal applications that can't change machine state, that's what metro apps are for.

3) Ability to a) Suspend all the processes and threads related to the isolated app, b) apply the most critical Windows updates to all memory and files, isolated or not, without reboot and c) resume.

Installing updates without a reboot is hard, because lots of those dlls that Microsoft are patching (like kernel32.dll and ntdll.dll) are already loaded in the address space of your programs - and Microsoft can't just overwrite them because your program might be using them, or have function pointers inside of them (e.g. from GetProcAddress).

Do you really want to be the guy spending weeks of time and effort building and testing the system to dynamically insert yourself into third party applications safely when your code is only going to run on people's machine between the update and the reboot?

1 day ago, androidi wrote

Also these "tasks" or apps in my testing often do not work with application virtualization, atleast not without spending bunch of time tweaking it - and the perf can suffer.

If they don't work with Application Virtualization they're unlikely to work with what you're suggesting, which is in effect how that works. And such a thing would still suffer from the problem that all such virtualisation solutions do, namely it becomes impossible for applications to interact effectively.