16 Comments

  • Personally, I think that moving the graphics system out of the kernel just makes sense. It looks like it just took them a while to figure it out...

  • That's a really severe distortion of what the article said. The veracity of the article is even in question, because they get the naming wrong in the first real paragraph, and the rest contains several other distortions. For example, Vista is no longer dependent on Avalon for the Shell, so it really wouldn't have any reason to run in kernel mode in the first place. Since most of the display drivers in the LDDM were already being moved to user mode, it's hard to tell if this article contains any information at all that is accurate.



    Microsoft's working to pull a bunch of things out of Kernel mode, because that makes the new Restart Manager more effective when patching. Files can't be unloaded to update if they are locked in Kernel mode, hence the reason for so many restarts in the first place.



    Either way, you took an already distorted article, and made it completely unrecognizable. Maybe you should start reading for comprehension as opposed to speed.

  • "Microsoft will move the graphics for its next version of Windows outside of the operating system's kernel to improve reliability, the software giant has told Techworld.



    ...Vista's graphics subsystem, codenamed Avalon and formally known as the Windows Presentation Foundation, will be pulled out the kernel because many lock-ups are the result of the GUI freezing, Microsoft infrastructure architect Giovanni Marchetti told us exclusively yesterday"



    I fail to see how what I said is a distortion of this. Regardless of the other benefits of moving the graphics system out of the kernel, the article's point is quite clear that the main reason is that it wasn't reliable enough to run in kernel mode. But I suppose Giovanni called you after he talked to techworld to give you the REAL story right?



  • I wonder if we will be able to dropin replace the subsystem with our own graphics system now?

  • I find the original article very confusing. What do they mean by "graphics"? Will the drivers run in user mode from now (as Robert seems to indicate? I would be VERY surprised if that was the case, and it seems it would be an incredbly late time to change these things in the dev cycle. Do they mean that WPF mostly runs in user mode? In that case this is simply not news at all. I also don't see how that would improve system stability. It always seemed to me that bad drivers in kernel mode posed the problem, the operating system code that runs in kernel seemed fairly robust for a couple of years now.

  • "For example, Vista is no longer dependent on Avalon for the Shell, so it really wouldn't have any reason to run in kernel mode in the first place."



    Now, that is confusing as well. The shell has always just been a normal user mode program. To argue that Avalon/WPF would need to run in kernel mode if the shell was dependent on it is completely wrong.

  • "Microsoft's working to pull a bunch of things out of Kernel mode, because that makes the new Restart Manager more effective when patching. Files can't be unloaded to update if they are locked in Kernel mode, hence the reason for so many restarts in the first place."



    This is not my area of expertise, but I think there are two mistakes in this. 1) The main reason MS is trying to pull out drivers (and other stuff as well) from the kernel is that a single bug in any code that runs in the kernel can crash the whole system, ie bluescreen it. The less code you have running in kernel, the less likely you will get a blue screen. Keeping 3rd party code (ie drivers) out of kernel mode is especially attractive there to MS. 2) Sure, if something is locked in general it is difficult to replace it. But I believe that having something loaded in the kernel doesn't by definition mean that you can't unload it. As far as I know you can unload code that runs in the kernel, if the code supports that.

  • I gotta go with Robert on this one. Your post makes it look like problems with Vista are forcing them to move the graphics subsystem. The article says it's being moved for increased reliability, and that Mac and Linux already run the graphics subsystem in user mode.



    It seems like a positive thing to me.

  • David, actually a Significant portion of WDDM drivers will be running in User Mode. as compared to XP drivers where the entire graphics drver runs in kernel mode.



    And the primary reason to move the driver to user mode is to reduce BSODS due to driver bugs.



    It should be noted also that this has been ongoing for several years now and builds off the WDF work where there is foundationial code. built in and IHV's now only have to concentrate on value add instead of rewriting boiler plate code.



    funny the article doesn't appear to have a clue to what has been going on for the past 3 to 5 years. for both vista and XP/2k3. not even a mention of completely removing from the kernel USB and Printer drivers etc.



    oh well. btw I believe the break down for wddm drivers is 10 to 20% is still in kernel with 80% of that code base wriiten by ms and IHV writing only the code necc for the hardware to run. all value add is in user mode.



  • The graphical subsystem in the kernel made sense, moving it out of the kernel doesn't, it creates overhead. If you truly want a microkernel, hte httpd subsystem also has to move to userland, but that will degrade iis performance so it stays. Strange? yes.



    Also, with having the graphical subsystem in userland doesn't make the system more stable. Yes, the kernel might stay up and running, like on Linux, but for the user, a crashing shell/UI is similar to a crashing box: everything s/he worked on in memory is gone. You can start the shell again, but what's the point? It's similar to the braindead remark we used to get from emm386: "I've stopped windows so you won't lose any work" "Hey crackpot, by stopping windows, you just made me lose my work!!!111"



    So in summary: stuff that has to communicate on kernel-level, has to be on kernel-level. If you can't get that right, something else is wrong and you should fix that first. If a videodriver causes most of the problems, make sure the videodrivers always work. MS already provides the DX layer, why not go a step further like with the printer drivers?

  • "Files can't be unloaded to update if they are locked in Kernel mode, hence the reason for so many restarts in the first place."

    MS controls what's going on in kernel mode. If the kernel can't swap out shared memory reliably, the kernel should be changed to do that properly.



    However that will hurt performance so they won't do that. It's not impossible, they just make a tradeoff, and the downside of that tradeoff is that other things have to be fixed instead.



    The graphical subsystem inside kernelspace always made sense and will make sense in the future, because windows isn't an OS that runs solely with a kernel and a very minimalistic Userland on top, it's an OS which has a GUI as one of its cornerstones. Also, the graphical subsystem is rather rudimentary anyway, it's not as if it draws its windows inside kernelspace.

  • "David, actually a Significant portion of WDDM drivers will be running in User Mode. as compared to XP drivers where the entire graphics drver runs in kernel mode."

    Sure, but if you're now going to claim that a videodriver can run completely in userland I'd suggest to read a book on OS design first.



    I agree that portions of a videodriver can be run in userland, however there's always a portion needed in kernelspace, for the simple fact that every videodriver 'bangs the hardware' as they saying goes, directly.



    A videodriver is not that hard: it has a subsystem which receives calls from the program, the calls are then transformed into internal calls and datastructures to be interpreted by the internal driver. The internal driver then executes these calls and uses the datastructures to manipulate the hardware to perform what it has to do. The system which executes what to do directly on the hardware has to be in kernelspace, you can't place that in userland. The code which transforms DX/OGL calls to internal driver code is a normal userland app/service and can run in userland. This is already partly done today in OpenGL: every extension dll is mapped in the application's memory space and calls into the conversion lib to transform the OpenGL calls into internal driver code, but the dll itself is userland code.



    What's unfortunate is that they refused to solve it properly. If you look at the printer subsystem in windows, which you noted as well fortunately, is that it's largely generic and is controlled by driving data, not really driver code. This means that you have a generic piece of code, which is controlled solely by data files, not some 3rd party kerneldriver which can write data everywhere.



    Because videodrivers have to squeese every cycle out of the hardware, it's a little hard to come up with a generic subsystem for this, but MS could have done more, for example by extending the DX stack so the videodriver writers could rely on data from the DX stack, instead of still doing a lot themselves.

  • "Also, with having the graphical subsystem in userland doesn't make the system more stable. Yes, the kernel might stay up and running, like on Linux, but for the user, a crashing shell/UI is similar to a crashing box: everything s/he worked on in memory is gone. You can start the shell again, but what's the point?"



    Well, that I can't agree with. For one: If something in kernel crashes, the system stops with a bluescreen. If some graphics subsystem would crash it would render the UI unusable, BUT applications could still save state to disc for example and recover gracefully without data loss. HUGE win for users, even if they had to boot anyways.

  • "Well, that I can't agree with. For one: If something in kernel crashes, the system stops with a bluescreen. If some graphics subsystem would crash it would render the UI unusable, BUT applications could still save state to disc for example and recover gracefully without data loss. HUGE win for users, even if they had to boot anyways."

    Agreed, though how would programs determine that the shell has gone belly up and they should stick around and save progress? The thing is: will Vista's gui die to a command prompt (as linux does) or will it simply render the system unstable? Even it if went to a command prompt so you could restart the shell, how would you map your running apps into the new shell so you can proceed? At the moment, when I kill explorer.exe it will restart itself and apps will reappear in that shell, but that won't happen of course in the case where the real shell is completely gone, as restarting the shell comes down to logging in again so mapping running apps into that new shell would be a security risk and probably not possible.



    So, every app has to become aware of a shell crash and act accordingly. I'm not sure how long that will take but it will take a long time before the majority of applications is updated for that. So in practise I don't see the huge win you described.

  • I think the statement is a little bit of a reach. Besides, the article has a number of inaccuracies.

  • Well, first we have to differentiate between shell and graphic card driver, right? The shell in Windows terms is explorer.exe. It never ran in kernel mode, so it has never been able to bring down the whole system. But a bug in graphic card driver causes a blue screen immidiately. It simply means that control is not handed back to any user mode process at all from that point on anymore.



    Now, if something crashes in a process in user mode, other processes can continue to run. Some things might not work anymore, if they depend on something in the crashed process, but if they handle that properly the process does not need to be shut down.



    The question remains: How could Windows notify a user mode process "Hey, actually, the whole UI is messed up. The user can't do anything anymore anyways, you better save your state quick so that I can boot". Well, I believe that is exactly what the new reboot manager in Vista is going to provide. Of course, apps need to support it, but the mechanism is there.



    But, let me just repeat this here: this is NOT how it is going to work in Vista. Parts of the graphic card driver will still be in the kernel. Any bug in that and you will have a complete stop of everything.

Comments have been disabled for this content.