(continued from previous page)
The system requirements guidance all along has been 512MB of memory (to run Vista), but earlier on a lot of people at Microsoft, I think yourself included, expressed a lot of confidence that the final version should run on systems with far less memory. Well, we got the final requirements this week, and it requires 512 megs.
Allchin: If I said it, I was wrong. I don't know if I said it, but if I did I was wrong. XP definitely works on lower memory. Our performance analysis today says that on low-memory machines, XP beats Vista, and the more memory you give it, Vista beats XP, and it's just because we're better at memory management, but we don't work as good on low (memory PCs) because we just have more stuff that we've got in the system.
One of the things that's very clear is Vista loves memory, and the more memory you put, the faster it will (be). It will not only be faster, but it will learn and get faster over time. So more memory is just a good thing for it.If you had to offer a list of a few lessons that the whole Vista development process has given you, what would be at the top? Allchin: Well, since about August or whatever--the middle of 2004--when we reset, I think we did most everything right. Before then, there has been a large postmortem on paper that I personally wrote on all the things that we needed to improve, which dealt with changing the engineering process, that had to do with dependencies, what dependencies you take at what levels and the projects at what level in the system, layering. Of all of the issues, I really think dependencies are probably the biggest one. I think it's an illusion and a mirage to say, "Oh, there's a better way to do this, we'll just ship software on the Internet, somehow the quality will improve and we'll do it faster." It doesn't work that way.
I do believe controlling dependency is something that for Windows is super, super important, and if you control dependencies, you make so much better progress. I mean, look at the server; the server with its new role--we'll set it up so that each of those roles can operate independently with a smaller development team that's working just on that role, so they don't have to worry about the others.
So when you look forward and you say, "Oh, it's just getting more and more complex"--the fact of making those things more modular and more so they can be independent but still work together in a common way through the management console and the like--but if you do that, you end up where the teams can be smaller, not as monolithic, and make faster progress. The same thing can be done on the client side.
In the future, more modularization, fewer dependencies are the answer. I'm a believer that cars or software, both will get more complicated in the future, and at the same time they will get simpler; you just have to mechanize, modernize the way you build them and the way the parts fit together. In an auto, the bus structure of how you plug in is pretty well-defined; you don't really get to mess around with the bus structure of the car. And so they have a lot of replaceability and they have a structure that you can plug in to. We just need to do more and more of it.
It seems that virtualization opens up some doors here. Apple Computer has obviously got a much smaller array of applications that they had to deal with this, but both when they moved to Mac OS X and to some degree when they moved to Intel chips, they said, "We need to make some changes forward, and this is how we're going to preserve compatibility." It would be a mammoth task, but is it something Microsoft is going to have to do at some point?
Allchin: I don't necessarily think that we would do it the same way as Apple did, because for a variety of technical reasons their problem is much simpler. But I can tell you that the top problem--I did a paper on the future of Windows--the top problem is this application compatibility, and we have a team who is doing prototypes for how we may have an answer to that in the future. We've got prototypes running with several different solutions about how to do this. It's a very complicated problem, more so than in the Apple case.
38 commentsJoin the conversation! Add your comment