Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
Windows Operating Systems Software Programming IT Technology

Going Deep Inside Vista's Kernel Architecture 478

Posted by Zonk from the from-the-horse's-mouth dept.
bariswheel wrote to mention an episode of 'Going Deep' on Channel 9 which takes a hard look at the architecture of Windows Vista. From the post: "Rob Short is the corporate vice president in charge of the team that architects the foundation of Windows Vista. This is a fascinating conversation with the kernel architecture team. It's our Christmas present to all of the Niners out there who've stuck with us day after day. This is a very candid interview." Topics discussed include the history of the Windows Registry, and the security/reliability of Microsoft's upcoming operating system.
This discussion has been archived. No new comments can be posted.

Going Deep Inside Vista's Kernel Architecture More

Going Deep Inside Vista's Kernel Architecture

Comments Filter:
  • Can someone post a transcript please?

    • Re:For those of us without speakers... (Score:5, Funny)

      by jtorkbob ( 885054 ) on Tuesday January 03, 2006 @07:51PM (#14388375) Homepage
      Sure! Here is my transcription of the entire link:
      Error: 503 Service Unavailable

      Server returned file not found
      Kind of sums it up nicely, if you ask me.

    • Not to diss the underlying interview [I'm always willing to hear about kernel stuff], but it's kinda odd that the MMS stream originates at a M$FT server:

      [Slashcode tends to put hard breakline characters and other weird white space into web addresses, so you will probably have to paste that address into a word processor and clean it up].

    • Transcript (Just Intros - Working On The Rest) (Score:5, Informative)

      by dch24 ( 904899 ) on Tuesday January 03, 2006 @10:05PM (#14389125) Journal
      Here's a transcript. I'll write up the other half and post it too. Anybody get the name of the interviewer? I'll just call him "Narrator." And the typos are my fault. Everything else, flame them.

      Narrator: Alright, so we're here for "Going Deep." We have the corporate vice president and some of his architects and they're going to talk about the Vista Kernel so, hello. Can you introduce yourselves.

      Rob Short: Yeah. I'm Rob Short, and I wrote the Kernel and Architecture team for Windows. The Kernel team obviously is the core piece of a system: schedules processes and finds devices, things like that.

      The Architecture Team is something that I wanted to talk a little bit about, because about two years ago, we realized that we were in a little bit more trouble in terms of our ability to predict the impact of changes and to make broad, cross-group changes to Windows, and what we decided to do was have a core group of experts that would help the teams and work right across all of windows to really help figure out the impact of changes and make sure things were happening the way we'd like to see them happen, and I have some of the people with me here today. This is just a few of the people on that team. We've about six people full-time, and we have a much broader team of about thirty architects working the different groups, and they all participate as part of our architecture team but they belong to the different teams

      Narrator: Okay.

      Rob Short: And the idea is to really improve our engineering process and improve our quality of our engineering and be able to predict the outcome of changes that we make.

      Narrator: Okay.

      Rob Short: I've been in Windows for basically ever, I've been in Windows for about fifteen years. I worked on a couple of other things in between, so I left and came back again but mostly I've been working on where the hardware meets the software.

      Narrator: Excellent!

      Rob Short: And I'd like to introduce my next partner in crime.

      Narrator: (laughs)

      Rich Neves: My name's Rich Neves. I've been working here almost three years. I work on the architecture team as Rob just described, and what my responsibility or role these days is is figuring out how to police the dependency between different pieces of the systems so that we can figure out how to compose the system in a more efficient way. By efficient, I mean in a way that isolates developers from the damage they can do to other developers. So basically, Microsoft's a very innovative company, and there's people working on amazing technologies in almost every nook and cranny, particularly in Windows. The challenge we face is delivering that innovation, and what our hope is that we can make innovation itself the bottleneck, instead of delivering innovation, which has been the problem in the past, and to do that, what we're trying to do is isolate pieces of the system from each other, so that developers can know that they can work in a particular area of the system, innovating a technology, without adversely impacting larger parts of the system, that as Rob said we can't predict they're going to be impacted, and in a way that would actually jeopardize our agility in getting those features out that result from that innovation.

      So specifically what we've been doing is taking every binary in the system and assigning it a layer number, which is a rank in a directed acyclic graph. There's about 5,500 binaries in the system. And what we've been doing is getting transparency now into every dependency that developers add to any of those binaries, so that we can understand what's going on. And what's falling out of that is not necessarily just the isolation I described, but also, issues. We call them, sort of, conventional wisdom ... controversies. For example, people might be thinking, well, I want to combine a whole bunch of DLL's into one DLL for perf. Well, it turns out that that's a

      • The thing that irritates me about the tone of Microsoft is that they still live in this world where they spin everything they do as amazing and its just not any more. Computers aren't "amazing" anymore. Operating systems and things like Windows does, even if new, don't have the same impact as the basic innovations of GUI displays did in 1992. The amazing stuff that is happening is, um, usually at Google.
        • And what has Google done that is so amazing? All they've implemented is a glorified "edit->find". There was that email thing that ... has more storage than their compeditors. Hmmm ... well, there was that map thing ... that is like all the other mapping services. Froogle? Wait, that is pretty much like pricewatch.com ... Google news? Nope, just another news aggregation website.

          I wonder if Google will ever do something that doesn't involve sticking a search engine on top of some existing technology.

    • Re:Transcript up to 34 min or so (Score:5, Informative)

      by dch24 ( 904899 ) on Wednesday January 04, 2006 @01:23AM (#14389988) Journal
      (this is the middle part of the transcript)

      Narrator: Fantastic. So can you talk a little bit about what's new in the Vista kernel? So we go from XP; now we're going to Vista. So what are some of the new components?

      Rob Short: A term I like to use is probably kind of politically incorrect on TV is, some of the work we do is kind of like sewers, but if we do this work incredibly well, the stuff is essential, but nobody knows that it's there.

      Narrator: Yes.

      Rob Short: So, if things go bad, obviously you know about it.

      Narrator: Certainly.

      Rob Short: Most of the work that I've been focused on for the last several years has been improving the experience where the hardware meets the software. Things like power management. We have a team of people looking at power management and working to improve how the system behaves, say a laptop for example.

      If you have a laptop, how fast does it turn on, turn off, how good is the battery life? What's the experience when you dock or undock? And we've done a huge amount of work on that. We've redesigned the algorithm for hibernation so that we do a better job of figuring out which pages are already on the disk so you don't have to send more of the pages back to the disk. We've changed the way the power management interfaces to the drivers so that we have a better feel for understanding if we can just shut this thing off, right now. Today, in the older system, in XP, we actually query the driver, say, "Hey, would you, like, mind if we turn off the power?" A lot of times, people haven't coded up the driver correctly. Mostly the drivers don't care, where some really do. A disk driver, it really matters if you, you know, turn the power off in the middle of a transfer. But a lot of other things, you don't care. Mouse, it doesn't really matter that much. You know, you can go across the extreme. So we've done a bunch of work in that area.

      We obviously do a lot of work in performance. One example is we had problems with heap fragmentation, and we've redesigned some of the heap algorithms so we can deal much better with much more random requests. We can deal with those and do a better job with defragmenting the heaps. So those are the types of things.

      Several people--Darryl works specifically on the multimedia, and understanding how we do a better job of not having glitches in multimedia, but that also goes right through the full length of the system. It's not just buried in the kernel.

      We've improved the inter-process procedure call. We have a new sort of fast, lightweight procedure call inside, in the core parts of the system. We ... stop me.

      Narrator: (Laughing) He has a whole list! A cheat list!

      Rob Short: There's an awful lot going on. One area where we actually make a lot of changes over time that I feel really good looking back is in the memory management area. If you think about the early NT systems, Bill Gates used to beat us up, and say, "How come you don't run in four megabytes?" And when you look at that today, and think, we're running regularly in four gigabytes today, and we have the systems in the lab that run with a terabyte of memory, the algorithms that worked back then, and the priorities back then are completely different than they are today. So we've put in work in Vista for improving the NUMA support, which is Non-Uniform Memory Access when you have a multi-processor where some of the memory is closer to some processors than to others, so we do a better job of doing the allocation, making sure that they're allocating memory that's on the CPU, near the CPU that you're running on, and then you try to run the process on the CPU where the memory actually is so you don't get cache thrashing.

      Narrator: Interesting.

      Rob Short: We've done some stuff for the graphics. The graphics processors today are more powerful than the CPU's were a couple of years ago. So what we've done is done a better job of partnering the core memory management with the graphics processor so we can actually keep windows in memory that are in memory not available to the graphics processor and then we switch it over and give it to the graphics processor, and say, "We happen to know this is a window that belongs to you. Let's flip it right over to that." So there are several of those kind of things.

      Another one that the people mostly on the server side will be delighted about is we've improved the way we do address space: the virtual address space allocation within the kernel. It used to be fixed allocated, the address space in the kernel, and that leads to some problems if you have a machine that has a lot of one particular type of structure. Say, someone is using up an awful lot of virtual address space. We ran out of page tables. We fixed that so it's completely automatic now in Vista.

      So those are just some of the things. And we've done some work to improve diagnosis. We've built what we call the "hardware error architecture" so that if hardware devices fail, there's a way to get that information back in a sort of common way back up to the higher-level software so that people can have a clue of what to do. You don't get a nice thing that says, "your device is bad." Okay. We'd like to be able to turn that into something that says, "this particular device has a failure of this kind."

      Narrator: Excellent. Now does that, that's not necessarily error handling, right? I mean, it's still, if you have a device error inside the kernel, running kernel mode you can still crash the system, correct?

      Rob Short: Absolutely. There's a big difference between actually detecting the error, and being able to get it to the right piece of software and then when you get to there, figuring out what to actually do with the error, whether it's recoverable or not, whether you can come up with a meaningful message. If we have failures in the kernel, we've made a policy decision that we don't actually know how bad it is, then we crash the system. And we try very, very hard not to do that so that you don't actually, you know, continue corrupting some information you keep running. But the idea is that for things that we understand the failure, we should be able to tell the user what happened, and a lot of that came out of the crash analysis data that we've done over the years.

      Narrator: Fantastic.

      Darryl Havens: We've also built a framework. Speaking of progress, we've also built a framework that allows us to run device drivers in user mode in a separate process. It's not inside the kernel, so it's not directly manipulating kernel data structures. It's not running in kernel mode in the first place. It's simply running in a user mode process, so you can, if something happens there, you can try and stop the user mode process and restart it. And your system comes ... it's not that your system comes back: your device comes back. It just, comes back up and starts working again without having the bug check the system.

      Narrator: Fantastic. Similar to the second application: applications crashing is a very...

      Darryl Havens: Right! It's a very special application, but yes, exactly.

      Rich Neves: So how does that work? I mean, how are you? How...

      Narrator: So in other words, so if you move, say, an audio driver up into user mode, there obviously has to be some abstraction layers, it has to, so the way you're passing, it has to eventually get back into the kernel information. So, how does that work?

      Darryl Havens: So basically, the device driver model before, and today still, for lots of device drivers is that when a request comes from a user mode process into the I/O system, the I/O system translates that into what's called an I/O request packet and it fills in the I/O request packet with all the information that we need for what is it this process is asking? Where are its buffers? Are they reading or writing? What's the operation that they're attempting to do, etc., etc. And then what you would normally do is just pass that to the first device driver in the line of the stack of all the drivers that you want to get to that eventually get down to the device to go say, "okay, here's what we're going to do."

      So what we do instead, today, is in some of these cases, the I/O request packet comes into what's called a reflector which then takes the I/O request packet from the I/O manager, packages up a bunch of data and does a, hands that off via an LPC, but very special LPC call, up to the user mode process which then turns around and performs operations on its behalf, and then when it's done, it goes all the way back around.

      Narrator: So it isn't really a performance issue in that sense.

      Darryl Havens: Well, depending on what kind of device you're going to use, it may or may not be. So the fact that this request, rather than being handed directly from the I/O system to a set of device drivers which could raise error Q.L. and lock out all scheduling in the system or dispatching of any, of interrupts or anything. Rather than doing that, when you hand that thing off to a user mode process. That user mode process, while it's special, is still a user mode process and it has threads, and those threads have to be scheduled against all the other threads in the system. So, if you don't set it up right, it's very possible for that thread to not get to execute for a really long time, in which case, it's possible that you could have some performance problems. But you know, you'd want to do this for something like a camera like this one, right? You wouldn't want to do this for, you know, your paging device. Or if you were sitting on a server, you wouldn't want to put the network driver in a queue for processing. Tell it to have at it.

      Rich Neves: Wasn't that LPC mechanism you described one of the things on Rob's list? Was that new, that up-call mechanism.

      Darryl Havens: Actually, it's not really an up-call, because basically what happens is when the user mode driver framework starts, it sets everything up and registers what's the reflector so that it knows what devices it's handling.

      Narrator: So I heard you mention something about glitch-free media? What's ... multimedia? Can we talk about that a little bit?

      Rob Short: Yeah, the problem we've got is, there are so many things going on in NT, and NT really isn't a realtime, you know, classic real time operating system, and at the same time, you want to be able to take a piece of video and you want to stream it, so there's the problem of decoding the video itself and then there's the problem of actually generating the pictures, and Darryl actually has worked mostly on this. It's across all of the different groups. It involves understanding the performance and time delays everywhere in the system and then figuring out what are the constraints and requirements on each of the different processes that are running. I prefer Darryl to actually tackle that one.

      Darryl Havens: So, basically the problem you get into any time that you start doing anything where a number of applications in the system are trying to get a lot of system resources and in some cases, there are, even on really high end machines today, there are video formats that it's not possible, if you had 100% of all the system resources, to actually decode the thing in time to hit the next frame. So basically what we've tried to do is we've tried to allow these kinds of applications to have as much system resources as they can possibly get, in particular, CPU, or memory, or whatever, but also have the system be responsive. So basically what we've built is we've built a scheduler that sits in the system; it's implemented as a service; and basically what it does is it schedules processes in the system, actually threads in the system, that have registered, that say that I'm in this multimedia class, and I'm busy doing one of these things, and I'm in the foreground right now, because you could have multiple windows, or one's laid on top of another one. You want the guy in the front to have as much resources as you can get because if it glitches, it doesn't do you any good if the guy that's sitting behind isn't glitching but the guy in front of you is just stopped, right? So you need to understand who is it that's in front right now, and in some cases, there may not even be a window, as I say, whether if you're capturing camera or something like that in real time.

      So basically what we try and do is we try and take all the threads that are associated across multiple processes in the system, all the threads that are associated with taking this particular video along with its audio, and boost their priority to really high, like completely out of the normal scheduling range altogether. So basically today what's going on is these guys just keep fighting each other and fighting each other, well they don't have the privilege to get out of the normal range so they're all sitting at 15, and they all think, "I'm the highest guy there is." Well, what we did was we figured out a way of taking some of them, some of the time, and running them between like 16 to 23! But we don't let 'em run there forever. So what we allow the system to do is to provide a cell that's a system responsiveness, and that says, "These folks are allowed to use up to 100% of the CPU time and the resources of the system unless somebody down here wants to use it," and then for some amount of time, ten percent or twenty percent of the time or whatever time you determine, those guys get a chance to run. So we take all these guys that were running way boosted, and actually put them underneath all the normal people, like your email program, or your editor, or something like that, and we just move them back and forth, based on the amount of CPU time that they're getting. So what that's allowed us to do is allowed us to give them huge amounts of resources, but not so much that your system becomes unresponsive. If you did this and didn't do it this way, and let 'em have as much as they want, you (A) probably wouldn't be able to move the mouse, but if you could move the mouse and then you clicked on something, the system would actually never see the click, right? You'd never be able to do anything like shut the window down. You just would never see that, right? So it chews all the resources in the system. That's where people are moving, right? 'Cause everybody's got the most important app there is, whether it's the game, or the video, or your email program, and you gotta get that email, I mean, you just gotta go out to the net and get the next piece of email. That's the most important thing in the universe.

      Narrator: Is this going to let people build new kinds of video games that run in a window, 'cause most the ... I went to talk to the Flight Simulator group; they said that, "I want the whole thing."

      Darryl Havens: Those guys are always going to want the whole thing because obviously the graphics looks way better at that ... they can do it both ways, but anytime you get full-screen it's going to look way better, whether you're the ultimate game or just playing a really nice high-def DVD or whatever.

      Narrator: Fantastic. So, can we talk a little bit about where we're going, like what the direction of NT is going. You talked about this at the P.D.C. Just talk about that a little more, the future of NT? Or the future of NT architecture, how's that?

      Rob Short: Yeah, we sort of, the way we look at the world at least in our group we've a very biased world, where we can get away with this and just be technology people, we're looking at the road map of the system for several releases, and trying to figure out where would we like to be with the system, you know, in five years, ten years, when we try and imagine where we'd like to be. And then the releases along the way are just snapshots of that, while the marketing guys would have a different thing where the release is the be-all and end-all.

      Narrator: Sure.

      Rob Short: But what we want to be able to do is have this to be one of the most fun places for engineers to work, and obviously we have to have exciting, challenging engineering work.

      Narrator: Sure.

      Rob Short: And what we've done is we've looked at the system from a few angles. One is most of the developers that you would be dealing with would understand this one: Richard at the end of the table is responsible for improving separation of state throughout the system, and over the years, the state in the system, which is anything from the user's files to settings to, you know, every piece of information that's scattered around the place. That stuff is not well structured in Windows. And it's grown organically. So if somebody wants to remember what their printer setting was, it gets stuffed off in some registry key somewhere. Well, now if you want to do a backup, the backup program has to know, find your registry key and back it up. So, we made a list of the toughest problems; we put state right at the top of that list. To be able to really change the system the way we want to do it, we have to get control of that. And Richard will probably come in a little bit more detail on that.

      Then we picked the layering and componentization work that Rich mentioned a minute ago. And I think he sold himself short; there's some phenomenal technology in that that I'd like him to talk about the technology ...

      Narrator: ... fantastic ...

      Rob Short: ... that they're using for that.

      Narrator: Excellent.

      Rob Short: But really understanding the layering and componentization so that we can do engineering in part of that, and that we can build pieces and really predict the outcome of the changes. That's very important. The application modeling windows is pretty complicated, putting it politely. We don't really know what the app model is. Lots of apps are slightly different. We're not quite sure where an app is supposed to put all its information. There are some guidelines that are out there; not everybody follows the guidelines. So we'd like some better guidelines on application models so that if someone wrote an application we can predict if the next version of Windows is going to break that.

      Another area that's fascinating is extensibility. Our whole world exists because of extensibility. And extensibility means somebody takes a piece of code that they write and put it into Windows and it changes the behavior of Windows. So a device driver falls into that category, a browser helper object, shell extensions, everything in between. Darryl Havens' figuring out what the future of those things should be. Now, for example, we'd like to be able know what they are before we load them, make sure they're not some spyware or some malware, or whatever, like have an idea where it came from. We'd like to be able to load it in the system. We'd like to make sure that if it fails, the system is resilient to that failure. We'd like to be able to inventory so that you can look at your system and figure out why it's crawled to a halt. Right, so you have to ... really understanding all the extensions and systems and crap inputs. We've got Darryl working on that.

      Narrator: Excellent.

      Rob Short: The other thing of course is compatibility, and there's a term that our Chief Software Architect uses that he says, "If you break compatibility, you're throwing away an asset." At the same time, when we change the system, we don't know if we're breaking compatibility sometimes, so we're looking at several different ways of using techniques such as virtualization to figure out if we can actually really guarantee that one version of Windows can always run the older applications, so those are the things that we're looking at from an architecture going forward ... they're some of the things.

      Narrator: Nice. Very, very cool. Let's hear about Layering. You're on!

      Rich Neves: So, the most important thing that we're trying to achieve is isolated engineering, as I said before. And Rob wanted me to talk a little bit about some of the technologies we're bringing to bear on that. Sorry. And, one of those technologies is something that Microsoft has had in its back pocket for several years now, which is technology from research that allows us to analyze binaries and understand their dependencies. So this means, this is very significant because it means we can look at compiled, engineered code, the binary, and determine what are the functional, and then of course, binary, dependencies on other binaries, even if it's dynamic dependencies. So for example, we can look at a binary, and the tools that we have allow us to do data flow analysis, and actually watch the values, the variables that occur, not as it's executing, but analyze it statically, and find that, oh, this has a COM dependency on this other GUID over here, or class ID, or we have a load library dependency on this function name in this binary. So we can find what nobody thought that we could be able to find, before, very very ... pretty accurately. I think we're ... I'm quite sure it's the owner of some of these tools would get mad if I claimed a percentage, but we're very ... we're approaching asymptotically the best that you can possibly do with this.

      So, given that as a basis, we now have, you know, the tens, or hundred thousands or so ... I don't actually know how many it is ... six digits of functional dependencies between binaries, and we have this wealth of information to look at. And we looked at it very, very carefully about two or three years ago, and our interest in this data was to understand ... how can we tease apart pieces of the system from the other pieces of the system to limit impact. So, just concretely, what if we wanted to, with 100% confidence, modify the shell, higher layers of the system, without worrying about retesting, or rebuilding, or rearchitecting the lower layers of the system. Now conventional wisdom would dictate that should be a problem. Well it turns out that of those 5,500 binaries I mentioned, using this information and these tools, about three or four hundred binaries are in what we call a strongly connected component, or more affectionately known as "the big cycle." These binaries are all IDE and shell binaries, and they were produced at a time, these dependencies between them were produced at a time when we didn't have any sort of discipline around taking dependencies. And this leaves us in a stiff situation where if you modify a higher level part of the system, you may well impact lots and lots of binaries underneath without even knowing it. And this limits our ability to not have to test, or engineer, or architect, or any verb you come up with for engineering, the entire system, which is very costly for us to do for the entire system. So what we think of today as Windows, we actually, from a dependency perspective, see as a single big binary. And now, you asked about the future road map of Windows, and what we're aggressively pursuing here is splitting Windows into at least two pieces in the first round, and, you know, N pieces in the longer term, where we have almost a firewall between the bottom and the top parts of the system. So that we have completely two separate engineering processes, two separate build trees, and we're able to actually build internal release engineering timelines that will allow us to get out of this lock-step engineering, where everybody's building their new features on the assumption that other new features will exist. So this is a very exciting reality if we can get to it, because we will be able to get out releases very, very, very quickly. We'll have teams pipelined developing new technologies in Windows, very, very quickly, and this is important because Microsoft's had, traditionally, very independent engineering teams, in terms of what they decide to work on, and that ... we'd like to keep as much of that as we possibly can, because it fires innovation, but we want to just federate a little bit of that, and understand how, if you could just follow these sort of guidelines, and not take these dependencies, we'll be able to let you go out, knock yourselves out doing some really great technology.

      So what we have now is an automated build process, and a peer review, an architecture process where if somebody takes a dependency that violates some of these axioms that we talked about, we've solved a lot of problems already that way. Our mantra so far has been to keep the system from getting worse in Vista in terms of dependencies, but at the same time, we've developed this map, like a ten foot tall map, a graph actually of all the binaries in one of the halls down here in building 26, and that ... what we've done in the process of not ... keeping things from getting worse is we've mapped out the entire system and now we can look at it and say, "We're going to partition it right here. And we're going to go ahead and have this be a separate NT tree, and this be a seperate NT tree."

      And the key thing here is that this isn't just about engineering isolation from a writing code perspective. It's also about architecture. Because now you can think about saying, "Okay, Joe Smith. We're going to have you be the architect for the networking stack. Not the IPsec stuff, just this network, the TCP/IP stack as it goes down to NDIS. And maybe some of the helper DLL's on top, and you're the architect for that." So now we can actually isolate architecture, and we can get some best practices that we defined by the domain experts in those areas, we can delegate to them, and say, "Keep those best practices in line." And now instead of having this very large system where we don't understand where the change is happening and the impact of that change, now we can go and delegate to the architects across the company who actually now can with confidence say, "I architect this piece of the system. And I know that if bad decisions are made in here, they're only made in here. I also know that I'm protected from the bad decisions made over here."

      And so we can catch things that are bad; they happen sooner, and get Windows towards a place where we are very agile and very equipped to get new features out to customers.

      Narrator: That's fabulous. That's absolutely amazing. And also be more perform... stable, more reliable, right? Fantastic.

      Darryl Havens: God, Rich! You guys get the good job. It makes me want to come work there. (laughter) That's great. Sorry, go ahead.

      Richard Ward: He makes it sound so easy. Sorry Rob.

      Darryl Havens: Yeah, exactly.

      Narrator: Oh, you just had to start, forty years worth of work, right?

      Rob Short: You've been very quiet. What's going on down there?

      Rich Neves: Yeah.

      Richard Ward: Oh.

      Rob Short: You could talk about state. You could talk about what we had to do with the system to make the protected admin work.

      Richard Ward: I didn't want to air all the dirty laundry. That'll ? in the future.

      Narrator: Oh yes, we did.

      Richard Ward: (laughs) Actually, I was actually hoping that Darryl would say ... actually serves as a good wrap-up, serves to see how everything kind of ties together, because around Louie? we've got a lot of goo in the system, both for applications, because applications spray their settings and their state and their installation options and all the other stuff, all over the place. And the system is even worse, and as much as we like to point at the apps and say, "Oh! If only Office didn't do that, we'd be better off." The reality is that it's the network stack and the Windows (he says it 'Vindows') stack, and the shell, and all the other areas that also ? all these problems, spread their idea of what things should be like everywhere, and it's hard to predict where things end up, and it's even harder to gather them all up again and move them someplace else for example. So, what's very cool about the states stuff is that it separates into different areas like application state, system state, and user state and preferences, we've made some inroads there in terms of letting user's configuration choices migrate with them wherever they go, but the state ... the system itself is still kind of like a big binary as Rich likes to point out. And so I look at when Rich is getting very excited about this layering work, yes it's very cool because as every area of Windows gets isolated in layering plan and area architects get assigned, I also know that we're going to capture and isolate the state for that particular area as well, because there's no way that you could have the engineering done in isolation of the rest of the configuration, so the layering map says that, oh okay, there's engineering value in people being the perspective on their own systems and propose as they do that they'll naturally be moving towards the more state-separated model where they have to capture what they want to do and carry it around with them. Because, otherwise they won't be sort of isolated, and so I've got that as a leverage point, and so my real task is to come up with a plan for how they're going to represent all their state settings and how they are going to be captured and contained and moved around. And we've got some minor ideas and we've got some projects going on about how we can change the way the registry works and we can do some interesting composite views and how we can leverage the class storage and the COM world and that sort of thing being done right now for once, how can we make that more prevalent, and how can we use the ? This could be very minor when you look at, okay let's take the whole system, split it into chunks that can be assembled in meaningful ways, and with every chunk of code, there's actually a chunk of state. That's very original.

      Rich Neves: So this doesn't necessarily remove dependencies. It makes it more understood what they are?

      Narrator: I mean is that fair to say? So in other words, it sounds like, 'cause on the one hand, it's componentizing the Operating System, or ...

      Rich Neves: Well, what I was talking about were functional dependencies between pieces of the system, and what Rich is, what Rich Ward is talking are state that's not necessarily aligned with how we partition off the system. So if two different binaries share a registry setting but they're at two completely different layers of the system, we've gotten a lot of isolation from a functional dependency perspective, but we still have this problem of unintended consequences of modifying that shared registry setting when it's shared by these two pieces, and that leads to all sorts of problems with trying to migrate people between machines and trying to just build systems that don't have some of those binaries sitting around. It's a real problem for us.

      Narrator: Do you guys wish the registry had never been developed?

      Rich Neves: The registry, I ... (laughter)

  • I love the questions they ask. (Score:5, Funny)

    by IntelliAdmin ( 941633 ) on Tuesday January 03, 2006 @07:25PM (#14388214) Homepage
    My favorite is: "do you ever wish the registry had never been developed?"

    • Re:I love the questions they ask. (Score:5, Informative)

      by Jugalator ( 259273 ) on Tuesday January 03, 2006 @08:00PM (#14388430) Journal
      I personally think the Windows Registry is the software implementation of the saying "putting all eggs in one basket".

      But of course, backups are automatically made on successful bootups to minimize the damage done if you'd suffer from a file corruption in that specific file. But I've never figured out when it does that. It clearly doesn't seem like on every successful boot, as I've seen messages like "Windows has restored a registry backup" and after that wondered where all settings the past few months went, and why some programs don't even run anymore. Gah... Thankfully last time it happened were a number of years ago. *knocks wood*

      Interestingly, Microsoft has started opting more for .config XML files stored in the application directory (sort of like their old .ini files) in their new wave of .NET applications, and that seems to be more like the recommended way of storing application settings. I don't know how user-specific settings are dealt with if doing it that way though, and if it's only suitable for settings for the local machine.
      • See:
                C:\Documents and Settings\\Application Data\
                (can be sync'ed with a domain server)
        and
                C:\Documents and Settings\\Local Settings\Application Data\
                (remains on this machine only)

      • Interestingly, Microsoft has started opting more for .config XML files stored in the application directory (sort of like their old .ini files) in their new wave of .NET applications, and that seems to be more like the recommended way of storing application settings. I don't know how user-specific settings are dealt with if doing it that way though, and if it's only suitable for settings for the local machine.

        There's a special directory for storing user-specific settings. On a default install of Windows

      • Re:I love the questions they ask. (Score:4, Insightful)

        by ivoras ( 455934 ) <ivoras@noSpaM.fer.hr> on Tuesday January 03, 2006 @10:10PM (#14389152) Homepage
        I'm sure that, if Microsoft did something like that (turn Registry into bunch of XML files), there would be an army of Slashdot-reading nerds going "Wow, M$ is stooopid - and what about memory consumption and speed of processing of all that XML files?!", "And just how is M$ going to ensure data reliability / transaction safety with textual XML data?!" and others.

        The Windows Registry in Windows NT systems is a database-like construct, with sort-of transactions. They even have access control lists to manage security - keys can be made writeable only by some users, etc. Some registry files ("hives") contain security information and are not readable by normal filesystem utilities (access-denied on open(); though this is not registry-specific :) ).

        Think of it like using mysql or sqlite database to store and manage system configuration instead of bunch of config files - it's NOT a bad idea.

        (I'm not attacking the config-file approach, just saying that having a convenient standardised interface to config data across all applications is a Good Thing).

        • Re:I love the questions they ask. (Score:5, Interesting)

          by smittyoneeach ( 243267 ) * on Tuesday January 03, 2006 @11:11PM (#14389423) Homepage Journal
          So why not do something intelligent and implement it as a SQLite database?
          What's less than half a meg of C that already works on Windows between friends? It's not like the existing registry files are exactly svelte.
          Ah, yes: good ideas can be discerned by the Redmond refusal to implement them.

          • So why not do something intelligent and implement it as a SQLite database?

            Feel free to travel back in time and suggest they do that. The registry has been around for over a decade. SQLite has not. The registry works (yes, maybe it can get corrupted, but I haven't had that happen in years), and there's other stuff Microsoft can and should focus on besides re-writing the registry.

        • Re:I love the questions they ask. (Score:4, Interesting)

          by klui ( 457783 ) on Wednesday January 04, 2006 @01:18AM (#14389961)
          Unfortunately, you cannot manipulate the data using standard Windows tools as though it were written as a set of files under NTFS. For instance, it would be really nice if I could search for all registry entries that was created/modified since I installed program X. The metadata exists, but is not exposed by regedit. And if something corrupts an entry in the file system, I think the chance of the entire hive becoming inaccessible is less than if the registry is in 1 file. Maybe I trust NTFS more than the registry "file system." Or are they done using same underlying calls?
        • Making state saving easy makes software tend to save more state. That makes said software behave differently each time it's started up. With bad developers, this can be highly annoying.

          Eivind.

    • What was his answer -- the site is down for me. If anyone here knows the history of the registry, please post it, as it seems like a tranewreck to most.

      • Re:I love the questions they ask. (Score:2, Funny)

        by Anonymous Coward
        I think the registry was an april fools joke that a PHB thought was a real idea.
      • Basically, they said that the registry was too successful for its own good; so many apps use it that it has almost become a general purpose database, which it was never intended to be. They say that one of the biggest problems was that there were never any comprehensive standards published on how it was to be used, so devs did whatever they wanted, which caused chaos that contributed to it becoming a mess.

        The registry first existed for registering OLE document types in about Windows 3.0. At the time, it ha
        • Personally, I don't see what the big problems with the registry are.

          With most old applications, I could simply copy the root directory onto another computer, and it would work fine. As apps started using the registry more often, this sometimes became impossible; programs would just refuse to work because they couldn't find the registry entries they needed. (Games are especially bad, as they often keep CD keys in the registry.) I can see why the registry could be useful, but in practice it (or perhaps jus

    • I designed the registry (Score:5, Informative)

      by the ed menace ( 30307 ) <edwardjung@hotDE ... com minus distro> on Wednesday January 04, 2006 @07:45AM (#14391161)
      ...I'll put on the asbestos underwear for this post...

      In 1990 at Microsoft there were several requirements that drove the registry. The number of third party applications and application writers was growing very fast. Making this worse, a new object system was on the horizon which could dramatically increase the number of independently-authored "components" that needed to be registered. There was a need to store state in a segregated manner so that apps wouldn't stomp on other app's information. Also there was a "new" notion of remote manageability for the objects, so the access method should be easily remotable early in the boot process. Also the OS needed a place to store lots of very small data items.

      It would have been best to use the file system, but the file system at that time was FAT which could not store small data items efficiently. The registry was the first API common between Windows 3 and OS/2 (and also NT), which was a goal at the time. Of course it quickly went out of control, since there was no rational security or ownership model. The registry was kept very very simple in order to maximize the likelihood that the next file system (either the object file system or NTFS) would be able to implement it, including in the NT kernel (which had a very simple API model). It was also the first API from Microsoft that had unused parameters for future features, such as context ids for security, query features, and other stuff. Unfortunately much of that didn't work as planned since very few applications paid attention to the requirement to set them to 0L!

      I didn't expect it to be so massively overused, nor for it to survive beyond Windows 3.x. It was supposed to be superceded by an object file system (that was designed and implemented several times, but never released.)

      There's a good story behind the registry, though: I designed the registry while on a bachelor party for a friend, mostly on a car ride between San Diego and Las Vegas, and faxed in the design from Las Vegas the morning after the party to the responsible program manager. Which might explain much about the design... ;-)

  • How deep did they go? (Score:3, Funny)

    by Spazntwich ( 208070 ) on Tuesday January 03, 2006 @07:28PM (#14388233)
    Because I'm only interested if it was BALLS DEEP.

    • Microsoft has been releasing a lot of Vista video "interviews" and tech intros lately. If you believed what they're trying to sell you, you would easily think that the Microsoft Vista teams are developing ground-breaking new technology for the benefit of us all.

      However, any remotely circumspect look at them will reveal that they're carefully choreographed attempts to show microsoft as a powerhouse with new ideas behind every corner... i.e., "Ohh look, here's Joe, the guy responsible for all this, right b

      • Re:You name it, they've probably been there. (Score:5, Insightful)

        by delong ( 125205 ) on Tuesday January 03, 2006 @07:55PM (#14388405)
        It must be nice to have mainstream consumers for your main customers, rather than IT pros. You can sell 'em anything, and they'll never know it's crap, because they don't keep up with the industry

        That's why I always skip all these "new Windows release" articles - they're pap. Usually just alot of mouth breathing over widgets and rather pedestrian implementations of mundane technology. Boring, and not very informative. Keeps alot of boring writers in jobs, though. Microsoft is like a 5 year jobs program for "IT Professional" writers that otherwise don't know their ass from their hat.

      • Re:You name it, they've probably been there. (Score:5, Insightful)

        by MightyMartian ( 840721 ) on Tuesday January 03, 2006 @08:26PM (#14388596) Journal
        Well, it was precisely this sort of hype that kept Windows 3.1 at the forefront while an actual 32-bit operating system that would run existing Windows applications (better than Windows itself) actually existed. Microsoft, through various "computer" magazines (which were nothing more than MS shills), painted a beautiful picture of Chicago, through artists renderings and feature lists for features that didn't even exist. Of course, when Windows 95 finally arrived, it was a bug-ridden piece of crap, but the marketing onslaught and MS's corrupt ways of dealing with PC manufacturers destroyed OS/2. People actually willingly went for one of the most unstable operating systems that MS ever produced.
        • Hey, OS/2 was also developed by Microsoft. Damned if you do, damned if you do it again.
          • Yes, because they got paid to develop it by IBM. However, they also did everything they could to sink it. See? They get paid to build it, they get to use the ideas to put into other Windows versions, and then they get to claim that actual competition existed at the time so as to look non-monopolistic. So what if they lost a bit in OS/2? They more than regained it through the marketing crush with 95.
          • They designed the 16-bit version of OS/2, but abandoned IBM and the 32-bit version and developed Windows NT instead. But it wasn't NT that ended up on the vast majority of machines in the mid 90s, but Windows 95. While OS/2 Warp was not a perfect operating system, it was miles ahead of Chicago, which was a real bastard child, unstable, with legacy support far inferior to that of OS/2. But MS won because it waged on all out marketing campaign for at least year, even when Chicago was essentially vaporware.
      • You are probably the same jackass who goes around crying "why doesn't Microsoft just do things like UNIX" and when they finally borrow a couple riffs you're crying"boo hoo, Microsoft is copying UNIX". It's clear they're damned if they do and damned if they don't do it's really no wonder they don't care very much about what the Slashdot community wants or thinks.

      • Re:You name it, they've probably been there. (Score:4, Interesting)

        by AnEmbodiedMind ( 612071 ) on Tuesday January 03, 2006 @09:53PM (#14389073)
        Yeah sure it is a clever marketing move, but you a way too harsh.

        For example one of the interviews with the vista audio engine guys they talk about how Mac OSX has been a long way in front and how they are inspired by great compeditors.

        They have an OS X box on the wall

        And if you look at the MS Office user interface work, you can't claim that isn't innovative work

        Finally if you actually watched the linked video you'd see they actually talk in depth about the flaws in the windows architecture and how they are trying to move forwards.

    • HAHAHAHAHA. I rarely laugh at posts but this one had me rolling for some reason.. Bravo!

  • Normally I'm a fan of the Deep Inside Series. (Score:5, Funny)

    by Anonymous Coward on Tuesday January 03, 2006 @07:28PM (#14388237)
    But that was the worst porn video I've ever seen. There wasn't even any nudity, but considering how these people looked (think your local linux user group visits The Gap), that was probably for the best. My rating? Totally Limp.

  • Please, kill the registry... (Score:3, Insightful)

    by Anonymous Coward on Tuesday January 03, 2006 @07:28PM (#14388238)
    ...good old ini files are much more easy to use (i.e. copy around, fiddle and the like)

    • Re:Please, kill the registry... (Score:5, Insightful)

      by dc29A ( 636871 ) on Tuesday January 03, 2006 @07:38PM (#14388305)
      ...good old ini files are much more easy to use (i.e. copy around, fiddle and the like)

      That will also make applications easier to port. Something Microsoft doesn't want. Registry is a good lock-in tool for Microsoft.

      • Re:Please, kill the registry... (Score:5, Informative)

        by Jugalator ( 259273 ) on Tuesday January 03, 2006 @08:16PM (#14388514) Journal
        Hmm... Well, assuming you have the source and are ready to start porting code, it's just about changing the behavior of a number of well documented [microsoft.com] API calls. You can make a library out of it with your own preferred behavior to make the code reusable. Actually, I'd be surprised if someone hadn't already done so and posted it somewhere on the web.

        It's hardly a lock-in method when it's both documented methods and it's easy to find out what happens -- the Windows registry is hardly rocket science, but more like a tree of settings that can have a few different data types.

    • Re:Please, kill the registry... (Score:5, Interesting)

      by displaced80 ( 660282 ) on Tuesday January 03, 2006 @07:52PM (#14388380)
      (I'm a .NET developer .... hey, don't shoot me!)

      I'm a huge fan of .conf files (or, on my home platform of choice -- OS X -- .plist) files. Although I appreciate .conf files' readability, sometimes I want to store prefs which are a little more complex. My preferred method is to create 'Prefs' classes in my apps. Depending on requirements, I'll make a UserPrefs class and optionally a SystemPrefs class (for prefs that apply to all users). These are just a bunch of properties to hold each setting. It's nice from a coding point of view because you can put sensible defaults into the prefs class(es)' constructor in case the prefs haven't been saved previously. I then just serialise and de-serialise these classes into and out of an XML file. These get saved into appropriate filesystem locations.

      The resultant XML isn't as tidy as that which OS X's Cocoa frameworks produce, but it's still a gazillion times more manageable and flexible than registry entries. I'd like to put together a generic viewer/editor for these xml files (much like OS X's 'Property List Editor'), although they're still plain-text tweakable if you're paying attention.

      The registry is an idea whose time has passed. I'd like to see a future MS operating system implement a standardised xml file layout for everything the registry holds, using as many individual files as are appropriate. Turn the legacy Registry API calls into wrappers for the file-based system.

      That'd make things neater, if done right! :)
      • Turn the legacy Registry API calls into wrappers for the file-based system.

        For those who don't know, this is actually exactly what Microsoft themselves did starting in Windows 4.0. They changed the implementation of a number of Registry API calls to work (read + write) against the registry rather than system .ini files. Time to change back to files again, maybe? ;-)

        • Topics discussed include the history of the Windows Registry

          I was hoping they would announce who was responsible, and kill him or her instead ... the registry should be classified as terrorist WMD - Windows Melt-Down.

        • I'm a huge fan of .conf files (or, on my home platform of choice -- OS X -- .plist) files
        • The resultant XML isn't as tidy as that which OS X's Cocoa frameworks
        • I'd like to put together a generic viewer/editor ... much like OS X's 'Property List Editor'

        So you're copying the way OS X does things within .Net to compensate for the way M$ does them. Sounds like you're ready for the Windows next-gen R&D team alright!

        =tkk

      • Although I appreciate .conf files' readability, sometimes I want to store prefs which are a little more complex.

        The configuration section doesn't have to be just a list of name-value pairs. You can design your own config sections with the full hierarchial functionality of XML. Look up the IConfigurationSectionHandler interface.

  • Fix whats there! (Score:4, Interesting)

    by a_greer2005 ( 863926 ) on Tuesday January 03, 2006 @07:34PM (#14388279)
    Not flame, genuine curiosity from a 20 year old IT major

    OK, am I the only one who has grown weary of the "oh well, another month, another insain exploit" state of mind in which windows users and admins seem to be willing to accept? Why do people just accept this, I understand a few bugs, and maybe a SINGLE large scale outbreak in something as commonplace as Windows, but this crap is just outright crazy now-a-days.

    Businesses would never accept this kind of qualty from, for example, partners, suppliers, and so on, so why do they "just take" this seeminly QC-lacking products from redmond with glee?

    • Re:Fix whats there! (Score:4, Insightful)

      by a_greer2005 ( 863926 ) on Tuesday January 03, 2006 @07:37PM (#14388298)
      Hate to reply to self but: heres the rest of my thought that I forgot:

      If you already paid for WinXP, why the hell should you have to pay AGAIN for the "security" that was supposed to be there...and in 2k, NT4, yadda yadda yadda?

      • I did notice today that Windows Live customers should not be affected by the WMF exploit. Guess you didn't pay ENOUGH just purchasing XP.

      • Re:Fix whats there! (Score:5, Interesting)

        by ThaFooz ( 900535 ) on Tuesday January 03, 2006 @11:12PM (#14389427)
        Fix whats there!

        A long term plan for fixing the underlying architecture problems is as important as maintaining the current release... otherwise you're just turd polishing (which is more expensive to Redmond & the end users in the long run). System Architects and QA are almost apples and oranges too.

        Not flame, genuine curiosity from a 20 year old IT major. Why do people just accept this... Businesses would never accept this kind of qualty from, for example, partners, suppliers, and so on, so why do they "just take" this seeminly QC-lacking products from redmond with glee?

        I really don't think there are that many people drinking the MS kool aid. People have been switching to Apple desktops and *nix servers fairly steadily, but you're not going to see an overnight change because the cost of migration is so high

        I mean for home users, it boils down to a Wintel system or an Apple... if you're buying a new system its an easy choice IMHO, but what does an unhappy windows user do if they have nice x86 hardware? What do you really expect non-tech-savy users to do when presented with the options of (a) selling their current sytem at a loss and buy new hardware, (b) really making an effort educate themselves for the purpose of switching to an OS with little-to-no commercial apps/games/tech support, mediocre media playback, and a clunky UI (no, I'm not hating on Linux. Fantastic workstation/server, craptacular home desktop) or (c) just accept it & hit the reset button/ bust out the system recovery disk every now and then until it's time for a new box (or a stable release comes out).

        For buisnesses, migrating workstations/servers is only possible if the application support is present, and you have the cost of re-training. Porting any custom C#/ASP/MSSQL/etc to cross-platform solutions is time consuming and software developers are expensive, ditto with *nix sysadmins. Not to mention the fact that any good Windows should be able to eliminate (or at least mitigate) the threat of said security flaws.

        If you already paid for WinXP, why the hell should you have to pay AGAIN for the "security" that was supposed to be there...and in 2k, NT4, yadda yadda yadda?

        Well I'm not exactly a MS fan, but I don't think its quite so sinister. Old versions (even pirated versions) are entitled to security patches for a few years, which is pretty reasonable. To expect lifelong upgrades for free is asking a bit much though. I mean, I expect Honda to issue recalls on any safety issues on my Accord, but don't angry when they won't retrofit it with a hybrid engine.

    • Re:Fix whats there! (Score:5, Insightful)

      by jjohnson ( 62583 ) on Tuesday January 03, 2006 @07:46PM (#14388351) Homepage

      Businesses would never accept this kind of qualty from, for example, partners, suppliers, and so on...

      Businesses in all markets accept this kind of quality from their suppliers and partners all the time. They don't like it, they scream about it, they change relationships because of it, but don't think that problems of the same scale don't constantly occur in businesses generally. I say this as someone who spent five years in plastic housewares manufacturing. Technology is not unique at all in this respect.

      • I say this as someone who spent five years in plastic housewares...

        Mr. McGuire: "I want to say one word to you. Just one word."

        Benjamin: "Yes, sir."

        Mr. McGuire: "Are you listening?"

        Benjamin: "Yes, I am."

        Mr. McGuire: "Plastics."

    • I believe the term is "conditioning" which replaced "brain washing". When you're used to getting something of a certain quality from a particular person or organization, you come to expect it. (That's the tech-savvy people who defend microsoft)

      Either that or you have no idea what a WMF is (May even think it's an acronym for a body part) and don't understand how it can hurt you or why it's important. (That's everyone else)

      Besides, usually with partners, suppliers, etc. you have a way of punishing them, perha
    • It's a combination of ignorance and complacency. People just don't know any better, and it doesn't annoy the decision makers enough to demand a change. If all you've ever known is Windows, then it's all too easy to think that everything else must be just the same. If you're a decision maker you're never going to get your hands dirty with the issue anyway, so who cares? You've got grunts to take care of that.

      Add to that the major hurdle of switching away from Windows, and you end up with the current business

  • What does this line of code mean? (Score:4, Funny)

    by Anonymous Coward on Tuesday January 03, 2006 @07:35PM (#14388282)
    if (defaultBrowser != MSIE || defaultMediaPlayer != WiMP || defaultMailClient != LookOut || defaultGUI != FisherPrice)
    {
    alert(Microsoft)
    }

    Heh, my "confirm you're not a script" is "issues." Not surprising.

  • Cue ominous music (Score:4, Funny)

    by CaptainCarrot ( 84625 ) on Tuesday January 03, 2006 @07:36PM (#14388291)
    Why do I get the feeling this is the programmer's equivalent of that scene in the teen slasher movies where the girl is going into the dark basement, unarmed and with nothing but a flickering candle for light?

  • slashdotted (Score:3, Funny)

    by Cmdr_earthsnake ( 939669 ) on Tuesday January 03, 2006 @07:40PM (#14388314) Homepage
    Click on link + server not responding + hosted on a microsoft server +MS publicity = slashdotted
    • Damn, good MS have come up with a scarier, uglier error page for asp.net? We are working on a new CMS in .net at my company. Those error pages seriously freak clients out. It looks like the world ended.
    • I assume that the database server is overloaded, so the cms is throwing an error. Couldn't there be a more graceful way to do that?
  • Holy shit, I just averaged 1.1 megs a second download! They are going too be hurting after this.

  • That's It?? (Score:5, Informative)

    by Spinlock_1977 ( 777598 ) <Spinlock_1977&yahoo,com> on Tuesday January 03, 2006 @07:53PM (#14388391) Journal
    Now I'm only half way through the video, but holy minimizer Batman, is that all they're doing?

    So they discovered software dependencies and configuration management, error handling in the kernel, and reversed one of their previous errors - putting device drivers inside the kernel.

    I'm no OS guru (I'm just an applications guy), but shouldn't they have thrown the whole mess in the garbage and started over? They're referring to the Vista kernel as "NT"!! It's freakin NT!

    NT's karma has waned (especially this week). God help us - we'll be stuck with MS security holes forever.

    • Re:That's It?? (Score:3, Insightful)

      by jonbrewer ( 11894 )
      Echoing the sentiments of the ACs who have replied to this, I too need to put in a good word for the NT kernel. It's excellent. It always works. I started working with NT 3.51 10+ years ago (same time I moved from Digital Unix to Linux) and have found it to be a great OS. Give it good hardware & software, (these days set it behind a firewall) and it will run for YEARS.

      I managed an early Y2K program back in 1998 where we moved a network from 486/Win3.11/Novell to 586/NT4.0/NT Server. We didn't put remova

    • Re:That's It?? (Score:4, Insightful)

      by 0racle ( 667029 ) on Tuesday January 03, 2006 @09:30PM (#14388958)
      Ah yes, throwing everything out and starting from scratch is a fantastic way to fix security holes and bugs.

      See Also:
      Windows 95
      Windows NT 3.1

      Paragons of stability and perfect programming without a single bug all thanks to throwing everything out and starting over.
  • Why is the audio quality of the movie so bad? Like this their American accent makes it very hard to understand anything if you are not a native English speaker.

  • Vista and WMF Vulnerability (Score:5, Informative)

    by blast3r ( 911514 ) on Tuesday January 03, 2006 @08:18PM (#14388532)
    I haven't read this anywhere yet but I did some testing today and found that Windows Vista is vulnerable to the nasty WMF dealio. I am wondering what else Microsoft is importing into Windows Vista? hmmmm
  • Slashdot editors provide free advertising for Microsoft spin doctors. Film at eleven!

  • Torrent (Score:3, Informative)

    by JRHelgeson ( 576325 ) on Tuesday January 03, 2006 @08:30PM (#14388624) Homepage Journal
    I can't believe that we /.'ed Microsoft!

    I just posted the torrent, enjoy:
    http://64.226.48.88/kernel_windows_vista_2005.wmv. torrent [64.226.48.88]

  • Vista and .wmf (Score:4, Interesting)

    by QuietLagoon ( 813062 ) on Tuesday January 03, 2006 @08:33PM (#14388635)
    the security/reliability of Microsoft's upcoming operating system.

    The answer to one question will determine whther Vista is really an improvement in security for Windows.

    Is the current test version of Vista susceptible to the .wmf exploit that is currently making the rounds on the internet?

    • Is the current test version of Vista susceptible to the .wmf exploit that is currently making the rounds on the internet?

      Yep, although you need to be logged in as 'the' administrator for the exploit to do anything to the system.

      Other accounts, even admin level ask for your permission to infect the system, so even with an open flaw, it would take the user to allow it to install. (And even some of the exploits still won't affect the system even with the user's permission with the new UAP system.)

  • About the security guy on the far right (Score:3, Funny)

    by aCapitalist ( 552761 ) on Tuesday January 03, 2006 @08:44PM (#14388716)
    I could barely hear the guy and the other architects were nudging him a little about being so quiet. I wonder why;)?

  • Dependency hell (Score:5, Interesting)

    by curious.corn ( 167387 ) on Tuesday January 03, 2006 @10:19PM (#14389187)
    So they're more or less admitting "essentially ... windows is one big binary..." Woah! Low level libraries and frameworks depending on stuff that's higher level, "in the past we've relied on... lockstep... development process..." and "we're now looking at dependencies in the 6 digits range..." Man, these guys are giving one hell of a bashing to the Microsoft codebase.

    One guy starts talking about modularity and inserting features and plugins into essential services... and I thought objC. But before that another one gets all hot (I chuckled, this guy is a True Nerd, he really likes fiddling with code... congrats) about semicoop multitask where an app renices itself to 100% resource hog tier for a limited time slot (nice try, but what when all the silly apps do the same trick?), but before that there's a talk about usermode ukernel services... I thought about when I used to renice X11R6 to get better performance (when the graph card module was part of the X process).

    I think Bill needs to pull out of tech and sell Microsoft to Apple. These techs are good guys, all they need is a solid process and some decent vision.

    Jobs, are you reading this? Watch this video, it'll make you feel good! :-)
    e

  • reality check (Score:5, Interesting)

    by penguin-collective ( 932038 ) on Tuesday January 03, 2006 @10:53PM (#14389328)
    First of all, the video is unviewable even with Microsoft Media Player on Mac, but you can find a whitepaper describing the kernel changes here [microsoft.com]. Keep in mind that all of this is basically Microsoft advertising for developers; it's not taking a "hard look" at the kernel architecture, it's the kernel developers portraying their work in the best light.

    What's interesting is how little innovation there actually is. They seem to be struggling with the complexity of the system and its dependencies (5500 components)--similar to the problems Linus is having, but multiplied many times over by greater complexity of the NT system architecture. Most of their actual improvements seem to be cleanups and performance enhancements.

    My impression is that the Vista kernel and system libraries are still playing catch-up with Linux in terms of modularity, performance, and functionality.

Slashdot Top Deals

If you are good, you will be assigned all the work. If you are real good, you will get out of it.

Close