© Charles Chandler

 

The nature of this architecture means that support for legacy applications need not be directly addressed. All legacy applications will install into, and run from, the user area. To put it another way, the user area will correspond to the entire hard-drive in existing OS installations. To support such apps that don't know about the new protected areas, there will be an instance of the previous version of the OS, where the legacy apps expect to find it. When they corrupt this OS, it will be broken for all legacy apps. But this will not affect the new protected OS, nor will it cause any problems for the new well-behaved protected apps.

 

As an alternative to maintaining a copy of the previous OS on the hard-drive, the OS vendor might decide to permit legacy apps to access the current OS. But the OS will then need a well-defined way of handling bad behavior on the part of these apps. For example, if a poorly-designed application thinks that it needs to write files into the System32 folder, the OS could intercept such actions, and redirect the file I/O to a folder elsewhere. Future attempts to access the so-written file could be redirected to the alternate location. In other words, the rogue app must be allowed to think that it has modified the OS, while in fact the OS remains fully insulated from all apps, and has simply handled all of the requests in an indirect way. While it would be non-trivial to catch every instance of such behavior, this might be easier than coming up with a legacy OS emulator. And this would mean that when a rogue app corrupts the OS, it is really only corrupting its "version" of it. All other apps, including legacy (unprotected) apps, would continue to function.

 

If this alternative strategy is taken, then without a legacy OS within the "user" area of the hard-drive, the user would see a hard-drive that would be empty except for the files that he/she had explicitly put there, and for the legacy applications that he/she had installed.