Microsoft's Allchin on the Longhorn timetable

Microsoft's Allchin on the Longhorn timetable

Longhorn is the code name for the next version of Microsoft's Windows operating system, but company officials have gotten increasingly sketchy about just when that time frame is

Longhorn is the code name for the next version of Microsoft Corp.'s Windows operating system, and the company often refers to the "Longhorn time frame" when discussing Windows and various associated products. But company officials have gotten increasingly sketchy about just when that time frame is. During an interview last week with Computerworld US, Jim Allchin, group vice-president of platforms, confirmed that the target date for the next version of the Windows client operating system is still sometime in 2005. Allchin also discussed the philosophy behind the company's operating system plans as well as the next service pack for Windows XP, which is due next year. Excerpts from the interview:

Microsoft Senior Vice President Paul Flessner displayed a slide at your TechEd Conference in New Orleans showing the Longhorn client targeted for 2005 and the next version of the server operating system projected for "2006+". We realize it's early, but what's the latest thinking about when they will ship and whether they will be synchronized?

It is very early, and we have a general plan that we're working to, which I'll explain at a philosophical level, but as to the point about when do they ship, are they synchronized, a lot of things can happen between now and then. It's still a long time off, and it's just too early. Philosophically, we want as many months, years, whatever, as we can keep the code base synced as possible. The efficiencies are huge by us doing that, and frankly, we think customers are best served by that.

So there was Windows XP. There's (Windows Server) 2003. We've now got two code bases that we need to service in the customer base. The server team was still finishing up while people were working on the Longhorn client. So now we're moving to where the Longhorn code base will be one, and we'll keep it one, client and server, for as long as we possibly can. And that's about as much as I'll say right now.

Is there a point at which the server needs additional testing, or where feature differentials come into play?

It's all technical reasons. ... For example, we have a new event system that we're working on because we think manageability is at the forefront of our next push, and so there has to be a piece in the client and a piece in the server. Now we'd like the teams just to focus on it being in one place, from a testing perspective. There are so many benefits for us to keep it synchronized. There's also synergy for us rolling out beta programs and testing programs and developer messages. It's just a little bit different if it comes out staggered.

We don't think it's the end of the world in any way, shape or form to not have it synchronized necessarily at the end. ... If we don't get it at the same time -- and there's a high probability we won't, by design, not because we slip up at the last minute but really we decide that we're going to have this much more testing on the server for that many more configurations -- we will then (let) a (service pack) of the client synchronize the code bases again.

It's only during the development cycle that it's really critical that you work with the same code base.

We think that it's very nice for a customer to come out with a service pack that can be applied, one media, that can be applied to anything -- server, client, whatever. It's much simpler if we can get it aligned from a code base perspective. So, for example, if we decide that there's an issue in the virtual memory system, the virtual memory system is one of these autotailoring systems that understands whether it's on a 4GB system or it's on a little tiny client. But if there's a bug in there, that bug could be fixed in both with one service pack. ... There's just a whole bunch of benefits for customers.

On the topic of service packs, the second service pack (SP) for Windows XP is coming out in 2004, correct?

If we don't change our mind. ... There are many things that can help drive that. In particular, the consent decree helped drive when we did SP1.

You talked about the advantages of synchronizing service packs for the client and server operating systems. Will the next service pack for the Windows XP client operating system also be a service pack for Windows Server 2003?

No. The reality is that the code bases are too different for us to synchronize it. We will keep two streams going on our current path. We can always change our mind, but right now we'll keep two code bases going until we hit Longhorn.

Will Service Pack 2 for Windows XP contain only bug and security fixes, or will there be new features in there, too?

It's all in a question of definitions, which I try to really caution people about. All right, is 64-bit a feature or is it not a feature? Is the fact that we're improving the wireless support for security, is that a feature or a bug fix? I mean, some of the wireless support that we produced just recently, we've already shipped it for WPA (Wireless Protected Access), for example. Was that a bug fix or was that a feature? So I think it's very confusing about what's a feature, what's a bug fix. ... The beauty is in the eye of the beholder.

Our general idea is that service packs are trying to be a rollup of the QFEs (quick-fix engineering updates), as well as other things that we have found internally that we think are important to deliver to customers.

Given that explanation, what do you expect will be part of the second service pack for the Windows XP client operating system, beyond the QFEs?

Stay tuned.

You mentioned 64-bit.

We're going to have 64-bit in the early part of next year, or before ... for a client version. ... We have a 64-bit client. All we're talking about is adding the support for a 64-bit extension to the X32-based architecture. ... We're going to do that client and server, linked to the service packs.

Then the service pack will come out in 2004?

We could decide to accelerate the service pack. It's not some hard-and-fast thing. We have a team. ... I don't want to get it locked down to a particular path, because something may come up. Something came up in the last couple of weeks. It's got a lot of focus here right now.

You're referring to the security issues in the last couple of weeks?

The worm. ... We have internal dates for the SPs, but we try to be a lot more careful. I certainly do, because I know that something might come up that makes us move those around, either because of our decision internally about what we need to do or because of something on the outside. So this worm doesn't have the major impact on that, but it's an example of what could.

Is the Longhorn client still on target for 2005?

It's all a question of probabilities. That's our target. But there's a probability it may make it, it may not. ... The truth is, these are targets. ... We'll know so much more when we hit Beta 1. And we're not going to be at Beta 1 at the PDC (Microsoft's Professional Developers Conference in Los Angeles in October). Once we hit Beta 1 we'll be able to get customer feedback. You can't predict when a product is going to ship until you get some customer feedback.

Beyond early adopters, enterprise customers are rarely itching to get the new release.

The press made an issue out of it for Windows 2000, made an issue out of the date vs. an issue out of quality. That's just my opinion having been here, because every meeting was about, "What's the date, and how far are you behind?" And my response is, I don't care. I only care about the quality. This was a monster release beyond anything we had tried to do.

I only care about the quality. You should be asking me about that. Forget the date. So that's still my mind-set as the engineer here. I do know that once customers are depending on it coming at a certain time, then we're in a different mode. But no one should be right now locking onto this. Let's see how the developers like it. Let's see how the Beta 1 goes.

Dates didn't become an issue for many customers until Microsoft instituted its Software Assurance program, where companies pay an annual fee with the expectation that there will be a new release of a product during the three-year time frame of their contracts. It sounds like Longhorn will place Windows on a four-year cycle, at a minimum.

We'll do right by our customers.

Does that mean --?

It doesn't mean anything other than we'll do right. We don't know enough to say anything more right now. I mean, I don't know the date. Is it early '05? Is it late '05? Do I have an issue where it's '06? I don't know. We'll do right.-- Computerworld (US online)

Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.
Show Comments