Linked by Thom Holwerda on Tue 13th Sep 2011 23:33 UTC
Windows Today, at Microsoft's BUILD conference in Anaheim, California, Microsoft unveiled the biggest overhaul of Windows since Windows 95. The venue was not coincidental; in the same city, in 1993, during the first Professional Developers Conference, Microsoft unveiled Windows 95 for the first time. Steven Sinofsky, supported by an army of Microsoft executives, demonstrated a whole boatload of things for Windows 8, and make no mistake, they had a lot to show. Two important notes: the Windows 8 Developer Preview will be free to download later today (no activation, will be updated regularly, and includes the new interface), and Win32 is the past.
Permalink for comment 489563
To read all comments associated with this story, please click here.
RE[2]: Not liking this so far
by joshv on Wed 14th Sep 2011 19:21 UTC in reply to "RE: Not liking this so far"
joshv
Member since:
2006-03-18

I think it's ok to have two environents if you must, - but not the way this is done.

There are several ways this is commonly done today:

- The compatibility environment is a walled off bubble within the host. Settings within the guest environment do not propagate to the host, and integration is minimal (cut/paste and file sharing). The guess manages it's own windows and creates it's own desktop.

- Apps within the compatibility environment are re-parented (at least visually) within the host's shell. For example VMWare's "Unity" functionality. Still integration is only visual, and settings and configuration done using guest apps don't affect the host.

- The legacy binary is run via an API wrapper that maps API calls to the native equivalents and provides a graphic canvas to the app within the host environment, managed by the host's window manager. Wine is an example of this. A similar approach, requiring a recompile, is a compile time wrapper that maps legacy APIs to the new APIs (Apple's Carbon).


So this suggests some possible approaches for Windows 8:

- Semi-virtual environment for legacy apps with their own OS images and file system. Desktop is a separate app, and integrated only via copy/paste and file shares. Metro is entirely legacy free and totally un-aware of Win32 or the desktop.

- Same as the previous, but do away with the desktop entirely. Create a metro-ized wrapper for legacy apps that runs the apps within the Metro shell.

- Unified OS installation, no virtual environment, legacy applications are run via a modified win32 API that makes the apps "look" at least more native and makes them function properly within the Metro shell.

My preference would be the second. It keeps the legacy cruft walled away, but at least allows the apps to function within the native Metro shell as peers.

Reply Parent Score: 2