More Windows 8 hints, this time on the virtualization front

More Windows 8 hints, this time on the virtualization front

Summary: Microsoft watchers have combed through a leaked slide deck about Windows 8 over the past couple of weeks for clues about Microsoft's next version of Windows. A French site, Ma-Config.com, this week unearthed some additional Windows 8 information, as well, specifically on the virtualization front.

SHARE:

Microsoft watchers have combed through a leaked slide deck about Windows 8 over the past couple of weeks for clues about Microsoft's next version of Windows. A French site, Ma-Config.com, this week unearthed some additional Windows 8 information, as well.

Granted, the new Windows 8 information is "old." It dates back to March 2009, when ITManager.com published the first part of an interview with Bernard Ourghanlian, Technical and Security Director with Microsoft France. Microsoft may have shifted its Windows plans and priorities considerably since then.

But the interview still contains some telling tidbits about Microsoft's thinking, regarding desktop virtualization and system updates which may become part of Windows 8. And given the fact that Microsoft officials said last year that systems-management/updating technologies would be key to Windows 8, I'm inclined to think at least some of what Ourghanlian discussed still holds.

(The interview is in French; I'm relying primarily on the English translation generated by Bing Translator, with a few of my own adjustments.)

Ourghanlian described the utopian Windows 8 situation: One where users would install a master of Windows on their PCs, plus possibly an antivirus program, but nothing else. All other applications would run virtually, via a combination of Hyper-V V3 (the next version of Microsoft's hypervisor technology, which would no longer be a server-only thing), App-V application virtualization technology and MED-V desktop virtualization functionality. Some of these applications would run in virtual machines that would combine applications and operating systems, i.e., an application running on Windows Vista or an application running on a particular flavor of Linux.

(Just a thought: Maybe this is what will enable the "push-button reset" capability Microsoft is said to be considering for Windows 8 will work...?)

In the ITManager.com interview, Ourghanlian explained:

"(I)f I for example Windows 8, I can imagine host images of Windows 7 systems Vista, Windows XP, or even for Linux. All this in a context where, virtualized way, I have these different systems images but in fact, the idea is to couple the two types of virtualization virtualization system and application virtualization are to ensure that applications, where they are compatible with an earlier version of the operating system but not with the current version, I can stream as App - V allows it, the virtual machine that is capable of supporting them. Therefore, the idea is for the user, this time in MED - V (Microsoft Enterprise Desktop) that will enable level shell, i.e. graphics, give the user the impression that there was a series of icons or applications which are available on his workstation thanks but, in fact, it is not known if this application is "running natively" on the native operating system of the machine or to a virtual machine. Now if we look at Virtual PC, this tool is suffering a huge disability from the perspective of the user. Based on a virtual machines, as many offices of virtual machine and therefore in fact many contexts of interaction between man and machine."

Currently, the App-V and MED-V technologies are available only to Microsoft Software Assurance licensees as part of a paid bundle known as the Microsoft Desktop Optimization Pack (MDOP). I wonder if the scenario above means Microsoft would make these virtualization technologies available to all Windows customers, not just those who pay a premium. Hmmm..

What's enabling all this, under the covers, is MinWin -- the "guts" of Windows (the kernel, hardware abstraction layer, TCP/IP, file systems, drivers and other core system services. Microsoft did include an implementation of MinWin as part of Windows 7, officials said last year. But it sounds like MinWin will be (not surprisingly) a lot further along with Windows 8.

MinWin will allow Microsoft to decouple many subsystems from the core of Windows -- including Internet Explorer, Ourghanlian confirmed. The underlying core that will be left will be the NT kernel. From the interview:

"Completion of MinWin is the possibility to make two fundamental things: you can disengage IE completely and be fully able to disengage the Shell, are things that are not yet feasible because these two elements are still too nested in Windows kernel. The goal with MinWin, when it comes with Windows 8 if everything goes well, it is to completely disconnect these features that is to ensure that potentially they are not present at all. At this time, this will allow to have, for the desktop, the equivalent of a Windows Server Core... in the case of Hyper-V V3 on the workstation is the smallest possible, both in terms of potential attack surface in terms of memory footprint and rack space disk."

(As a refresher: Here's a slide from a presentation in 2009 by Microsoft Technical Fellow Mark Russinovich that explains what MinWin is/isn't in a succint way.)

Another area where Microsoft's next-generation virtualization technology will come into play with Windows 8 is in the Windows update space, as Ma-Config.com explains in its latest blog post. Managing all the virtual machines enabled on the desktop via Hyper-V 3 will be of great importance with Windows 8. Updating virtual machines while they're turned off, as well as updating third party applications, will need to be managed via new Windows Update mechanisms, as Microsoft Kitchen blogger Stephen Chapman noted (via a Microsoft Windows 8 job post he found last year).

It's still early days for Windows 8, and as I noted from the outset, a March 2009 interview (published before Windows 7 was released to manufacturing) is pretty ancient Still, there's some good food for thought about what "might be" coming when Microsoft delivers its next version of WIndows (in 2013 or, hopefully sooner, given Apple's growing dominance in the slate PC category).

If you wade through the ITManager.com and/or Ma-Config.com posts (especially any of you fluent in French), I'd be interested in any additional take-aways you find....

Topics: Operating Systems, Hardware, Microsoft, Software, Virtualization, Windows

About

Mary Jo has covered the tech industry for 30 years for a variety of publications and Web sites, and is a frequent guest on radio, TV and podcasts, speaking about all things Microsoft-related. She is the author of Microsoft 2.0: How Microsoft plans to stay relevant in the post-Gates era (John Wiley & Sons, 2008).

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

56 comments
Log in or register to join the discussion
  • RE: More Windows 8 hints, this time on the virtualization front

    Great, but seems like they are still not going to dump registry crap. I hope they will...
    shellcodes_coder
    • RE: More Windows 8 hints, this time on the virtualization front

      @shellcodes_coder i dont see whats so wrong about the registry. in the windows 9x and xp days, yes the registry was a problem as they didnt implement any mechanism to protect or keep its integrity. however, Vista and Win7 are totally different beasts. Win7 has shown itself to be rock solid. its my OS of choice and the only one i put my word behind.

      the registry has its disadvantages and its benefits. and at this point its benefits are greater
      blazing_smiley_face
      • Don't forget to add WHY it's not so bad any more...

        @blazing_smiley_face
        You know, since Vista, Microsoft has been enforcing "best practices" - like NOT using the registry as a messaging system between multiple modules of an application (Intuit) or a dumping ground for any and all crap an app wants to store for whatever reason. Stuff that gets forgotten and clogging up the works.
        Wolfie2K3
      • Don't forget to add WHY it's not so bad any more...

        @Wolfie2k3,
        The registry isn't designed to be used for general storage, or as a messaging system...it's for configuration settings. With Vista and Win7 the registry hive was improved to include registry virtualization, which keeps programs that don't respect least privilege principles from writing to HKEY_LOCAL_MACHINE. In addition it also wraps updates to the registry in transactions so that they can be rolled back if there is an error. The upside to the registry is that you can manage thousands of desktops from a central location. This is something that continues to be a selling point of Windows in the corporate environment.
        bmonsterman
      • RE: More Windows 8 hints, this time on the virtualization front

        @blazing_smiley_face

        "i dont see whats so wrong about the registry."

        CLSIDs - long strings of meaningless but important numbers.

        Duplicate keys in several places.

        Applications that do weird things.

        A hierarchy that makes absolutely no sense.

        The fact that users STILL have to edit the thing to do what they want, because some developers think hidden features and options are cool.

        I honestly don't see what's so right about the registry.
        CobraA1
      • @Cobra

        [i]CLSIDs - long strings of meaningless but important numbers.[/i]

        What does that have to do with the registry? This is a product of COM, not the registry. If MS didn't use the registry and used C:\etc\ config files, they would still use CLSIDs to keep track of COM DLLs. And no, I'm not saying COM DLLs are good, they really aren't (.NET + GAC is far better), but don't blame that one on the registry.

        [i]Duplicate keys in several places.[/i]

        The only time I've seen duplicate keys in several places are where settings are stored at the system level and again at the user level. I've seen the [b]exact[/b] same thing used in Linux with /etc/ for system level settings and the exact same settings in the /home/ directory for user settings.

        [i]A hierarchy that makes absolutely no sense.[/i]

        How does it not make sense to you?

        [i]The fact that users STILL have to edit the thing to do what they want, because some developers think hidden features and options are cool.[/i]

        Wow, and I've never had to manually edit a config file in Linux because a Linux developer thought hidden features and options were cool. Oh. No. Wait. I had to do that all the time.
        NonZealot
      • RE: More Windows 8 hints, this time on the virtualization front

        @NonZealot <br><br>"This is a product of COM, not the registry."<br><br>A mess is a mess, no matter who creates it.<br><br>"How does it not make sense to you?"<br><br>How many places does "software" need to be under? HKEY_CURRENT_USER? HKEY_LOCAL_MACHINE? HKEY_USERS\(horrid_number)? HKEY_CURRENT_CONFIG?<br><br>What wise guy thought ALL_CAPS_WITH_UNDERLINES_BEGINNING_WITH_"HKEY" was user friendly?<br><br>If this makes sense to you, I'd like to see something that doesn't make sense.
        CobraA1
      • @Cobra:

        [i]A mess is a mess, no matter who creates it.[/i]

        Then Linux is a mess because Linux runs the Internet and the Internet allows pedophiles to swap pictures. Give me a break.

        The registry does not rely on CLSIDs. COM relies on CLSIDs. Therefore, your issue with CLSIDs have nothing at all to do with the registry. Like I said, get rid of the registry without getting rid of COM and all that will happen is all those CLSIDs would move to a config file. Would you then hate config files?

        [i]How many places does "software" need to be under? HKEY_CURRENT_USER? HKEY_LOCAL_MACHINE? HKEY_USERS\(horrid_number)? HKEY_CURRENT_CONFIG?[/i]

        Like I said, there are settings at the user level and at the machine level, just like with config files. HKEY_CURRENT_USER is a link to one of the HKEY_USERS entries and makes it easy to modify the current user's settings without having to know who the current user is.

        How many places does abcde need to store config settings?
        http://lly.org/~rcw/abcde/page/abcde.1.html
        1. /etc/abcde.conf
        2. $HOME/.abcde.conf
        3. /home/cobra1/.abcde.conf

        AAARGGH!!!!! SO CONFUSING!!!!

        [i]What wise guy thought ALL_CAPS_WITH_UNDERLINES_BEGINNING_WITH_"HKEY" was user friendly?[/i]

        It bothers you that the first level uses all caps with underlines even though nothing underneath it does? Seriously? Wow. Okay then, since when does /etc mean "here is where you should put all your configuration files"? Do config files suck because /etc is a bad name?
        NonZealot
      • RE: More Windows 8 hints, this time on the virtualization front

        @NonZealot<br><br>"Then Linux is a mess . . ."<br><br>Not that I care. I run Windows. Despite its faults, I still find it to be a decent OS.<br><br>"The registry does not rely on CLSIDs. COM relies on CLSIDs."<br><br>Quick question: Who makes COM? Do they not work for the same company that created the Registry??<br><br>"How many places does abcde need to store config settings? "<br><br>Windows had its own set of config options (some of which, despite all the Registry stuff, are still floating around - boot.ini?), and applications had their own in their own folder (and often still do!). Seemed pretty simple to me.<br><br>"It bothers you that the first level uses all caps with underlines even though nothing underneath it does? Seriously?"<br><br>It takes something that's already complex by nature and just makes it worse.<br><br>"Okay then, since when does /etc mean 'here is where you should put all your configuration files'?"<br><br>I don't understand why Linux does things the way it does either.
        CobraA1
      • RE: More Windows 8 hints, this time on the virtualization front

        [i]Quick question: Who makes COM? Do they not work for the same company that created the Registry??[/i]

        Yes, and nowhere was I absolving MS of any of this. I just find that people hate the registry for reasons that have nothing at all to do with the registry. COM is one of those reasons that pops up a lot. Yes, MS is 100% to blame for DLL Hell. Still doesn't change the fact that the registry has nothing at all to do with COM. Like I said, if MS were to switch to config files tomorrow, would you suddenly hate config files because of CLSIDs?

        [i]It takes something that's already complex by nature and rubs it in.[/i]

        I'll ask again, it seriously bothers you that much that the top layer, and only the top layer, uses all caps and underlines?
        NonZealot
      • RE: More Windows 8 hints, this time on the virtualization front

        "I'll ask again, it seriously bothers you that much that the top layer, and only the top layer, uses all caps and underlines?"

        Yes. Does it bother you that it bothers me?

        What does "HKEY" mean anyways?
        CobraA1
      • RE: More Windows 8 hints, this time on the virtualization front

        @nonzealot<br><br>"How many places does abcde need to store config settings? <br>1. /etc/abcde.conf<br>2. $HOME/.abcde.conf<br>3. /home/cobra1/.abcde.conf"<br><br>You do realise 2 and 3 are the same.;-)<br>Why not add:<br>4. ~/.abcde.conf
        Richard Flude
      • @Richard: Yes, that was there on purpose

        [i]You do realise 2 and 3 are the same.;-)[/i]

        That was a little reference to Cobra's previous statement that I quoted right before I wrote that:
        [i]How many places does "software" need to be under? HKEY_CURRENT_USER? HKEY_LOCAL_MACHINE? HKEY_USERS\(horrid_number)? HKEY_CURRENT_CONFIG?[/i]

        I even added this which should have made it all the more obvious to you that I knew exactly what I was talking about:
        [i]HKEY_CURRENT_USER is a link to one of the HKEY_USERS entries and makes it easy to modify the current user's settings without having to know who the current user is.[/i]
        NonZealot
      • @Cobra: Nope

        [i]Yes. Does it bother you that it bothers me?[/i]

        Nope. I just figured we were going to stick to listing good arguments for why the registry sucked. If I said "I hate the name /etc therefore config files sucked", I would hope that someone would call me on it, for my sake.
        NonZealot
      • RE: More Windows 8 hints, this time on the virtualization front

        @CobraA1: HKEY = handle to registry key
        shellcodes_coder
      • RE: More Windows 8 hints, this time on the virtualization front

        "I just figured we were going to stick to listing good arguments for why the registry sucked."<br><br>Please give me a non-emotional argument for why ALL_CAPS is a user friendly design.<br><br>Otherwise, your argument is no less emotional than mine.<br><br>Maybe this will help:<br><br>-It's not consistent.<br><br>-ALL CAPS are generally more difficult to read.<br><br>-"HKEY" is not an intuitive description.<br><br>-Users won't know that there's an internal structure that redirects HKCU to HKU.<br><br>-Seeing duplicates between those two structures is likely to cause confusion..
        CobraA1
      • RE: More Windows 8 hints, this time on the virtualization front

        @CobraA1,

        CLSIDs are not meaningless numbers, they are GUIDs (Guaranteed Unique IDs). In COM if you use early binding (compile time) the lookup for the location of the dll uses the GUID. Problem with using early binding is that if you make a change to a COM object that breaks binary compatibility, a new COM object with a new GUID is created and it replaces ( best practice ) the COM entry of the old object. So you have to go back to all of the consumers of that old object and recompile using the new reference. If you use late binding it looks it up by progid (which is more meaningful to the human eye). The problem here is if you make a change that breaks compatibility and register the new object without unregistering the old object, there will be two entries in the registry with the same progid and COM subsystem won't know which one to load. This is what dll hell is and we can all agree that COM was a poorly designed system. Microsoft continues to release software dependent on this paradigm, and for the life of me I don't know why.
        However, the registry for the most part has been replaced with GAC, which allows for the versioning of said dlls and solves the dll hell problem.
        This really has nothing to do with the registry. It's just a poor use of the registry. As far as using a central location for all program configurations versus using disparate config files...it's just a matter of style. There's a trade off, one allows for a single point of failure, the other is a maintenance headache because the location and structure of each config file can be different. It's useless to argue about it, kinda like the "Taste great, less filling" argument. You have to know what is important for you and go with that.
        bmonsterman
      • @cobra: I said no such thing

        [i]Please give me a non-emotional argument for why ALL_CAPS is a user friendly design.[/i]

        At NO_POINT did I ever say that ALL_CAPS was a "user friendly" design and I won't start now. What I said was that if you hate the registry because the top layer, and [b]only[/b] the top layer, uses all caps, then I can hate config files because they are stored in /etc and that isn't user friendly either. Of course, I wouldn't say that I hated config files because they were stored in /etc because that would be a stupid reason for hating config files.

        So yes, all caps isn't nice but who cares. Users don't see it. Admins have to deal with [b]far[/b] less intuitive issues on all OSs. It is only the top layer.

        [i]-Users won't know that there's an internal structure that redirects HKCU to HKU.[/i]

        Users don't go into the registry and on the rare occasions where they do, they are following specific instructions on where to go and won't ponder the confusing concept of links.

        [i]-Seeing duplicates between those two structures is likely to cause confusion..[/i]

        Did you not see Richard's post just above this one where he chastised me for not realizing that ~/.abcde.conf pointed to the same place as $HOME/.abcde.conf and /home/cobra1/.abcde.conf? Of course, I did realize that and it was to show that this happens in [b]exactly[/b] the same way with config files and for the [b]exact[/b] same reason. HKCU and ~/ are both important because they allow config scripts to easily configure something for the current user. It isn't confusing to admins (because admins are used to this concept) and it isn't confusing to users (because users don't typically edit either the registry or ~/.abcde.conf.

        If you are going to point out negatives about the registry, they should at least be negatives that aren't [b]exactly the same[/b] with config files.
        NonZealot
      • RE: More Windows 8 hints, this time on the virtualization front

        I'm not sure people bothered arguing about Linux's structure - because I *never* proposed that Linux had a good design.
        CobraA1
      • RE: More Windows 8 hints, this time on the virtualization front

        @blazing_smiley_face I just figured we were going to stick to listing good arguments for why the registry sucked. If I said "I hate the name /etc therefore config files sucked", I would hope that someone would call me on it, for my sake.
        timaeus