Allchin Talks Up Longhorn, 64-Bit Computing

By eweek  |  Posted 2004-05-10

Allchin Talks Up Longhorn, 64-Bit Computing

Microsoft Corp. used its recent annual WinHEC conference in Seattle to give more specifics about the roadmap for the release of Longhorn, the next version of Windows, as well as to talk up potential future adoption of 64-bit computing. Jim Allchin, Microsofts group vice president of platforms, sat down with eWEEK Senior Editor Peter Galli after his keynote address.

You talked about a new technology that allows devices and PCs to power up from a "sleeping" state in under 2 seconds called "Instant On" in your keynote. Is this technology in any shipping products yet?

This is fabulous technology, and the work around this has been quite something. We havent decided when to include it in a shipping product as yet, but it will be soon. What you saw was work that dealt with a whole lot of the peripherals, but we can get the amperage down to 50 percent if we do the rest of the work. We are almost there, and that to me is just a mindblower in terms of the impact it can have.

Microsoft has been talking a lot about the potential pervasiveness of 64-bit computing by the time Longhorn ships. Do you agree with that scenario?

I see the adoption of 64-bit computing moving pretty rapidly as I see few compatibility issues, other than the drivers, which could slow it down, and thats another reason why we have to take a hard bet on it. So the compatibility is very good in terms of applications, and the second thing is the cost: Conceptually theres no price difference. If thats true, then, wow, why dont you get it and make the 32-bit applications running on the 64-bit operating system faster, and there are other nice neat things about address spaces.

So, will Longhorn be based on a ?

We will have a 64-bit version of Longhorn, no question. Will we have a 32-bit version? The plan is yes, but now, if we learn a lot between now and then, that might change. But right now we are staying the course and it is so hard to predict how fast the run rate will be. We know where AMD [Advanced Micro Devices Inc.] will be, we know pretty much where Intel [Corp.] will be. I think we just have to wait a little bit.

So, if you decided not to have a 32-bit version of Longhorn, those customers would not get Longhorn?

Thats why were not going down that road. Theres no reason why we have to do that. Its sort of an academic discussion.

Can you tell me what the reference architecture is for Longhorn?

I dont know if thats public yet. Youre talking about memory size, processors and all that? I dont think weve made a final decision,n and I dont think we will until we hit Beta 1. We have targets inside, and we may have gotten feedback on this from some select people, but its just too early.

Next page: Syncing Longhorn releases.

Longhorn in Sync

You have shifted your strategy on the Longhorn client and server release cycles, and you are now developing them pretty much in tandem so they can ship close together. What drove the change in your thinking on that?

Internal efficiency. The alternative was to add a ton more functionality to the server so it would have taken longer. But the problem was that it meant we would have run two different source trees with all the shared components having to deal with both, with two separate runs on beta testing. The coordination effort means that while the server will not have as many features as it would have when we planned to release it two to three years after the client, but now you get all of the benefits and there will be a synchronized system until the very end, where there will be a longer test. We will take whatever time is needed to finalize the server, but it will not be years though. Basically, well keep it one milestone behind and at the end, around Release Candidate time, well let it bake a little bit longer.

Click here for more on Microsofts plan to sync Longhorn releases.

But that was the early plan with the Windows XP and client releases, and they shipped years apart. Is that same scenario avoidable here?

We think so. The amount of IQ that we have on the software engineering process is incredible at this point. The level of people working on our source and build environments and our tools now are so smart. Before we didnt have the MIT guys; we have now applied real hardcore brilliance to the problem. Were putting the dollars there, and I anticipate [what happened with XP] wont happen again. We didnt think internally that the pain with XP was going to be as bad as it turned out to be, and none of us want to do it again, we really dont.

We all know by now that you plan to cut some Longhorn features. What is currently on the chopping block, and do you have a sense for what might be cut?

The first thing you have to put in context is the magnitude of Longhorn. The things that we cut you did not even know were there and most of the people working on Longhorn did not know they were there. So, its not like the storage system, the graphics system or Indigo are not still going to be there. All the work on basics is still all there. There are things we wished that we could do that weve now decided to move to Blackcomb. There is spreadsheet after spreadsheet of little line items that when you look at them we say we just dont need those now. The one thing about Longhorn is that the quality is going to be there. This security situation is going to be addressed. We have done a very good job with Windows XP SP2, and we are redoubling, tripling, our efforts to ensure that the quality base is beyond anything weve ever done, and I would cut other features out without even thinking about it to make sure that I do a great job on security. Theres so much in Longhorn, it is so overwhelming and the specific things we cut were wish-list items really.

Next page: Finalizing the feature set.

Finalizing the Feature Set

When will the feature set be more final?


For a look at the latest Longhorn build, click here.




Absolutely. They are cloners.







Next page: The upgrade issue.

The Upgrade Issue






Click here for more on Red Hats Linux desktop.



Rocket Fuel