Feeds

Compaq responds to Register Alpha NT stories

It was Q what done it, not MS

  • alert
  • submit to reddit

Secure remote control for conventional and virtual desktops

Letter After a series of articles we wrote in the last ten days, Jim Boak, the director of Compaq’s Corporate Technical Strategy in the US, has written us an email outlining his company’s position. The full text is below. Stories, with links related to other stories in this letter are How Microsoft hedged its 64-bit NT Alpha bets, MS trashes own 64-bit plans by killing Alpha NT and How a leaked Pesatori customer letter reads Some of your posts in The Register have been referred to me. I'm sure you want to post accurate information, although the truth may not make quite as good a story as those articles in the current press. We will be working over the next weeks to clarify the details behind Compaq's decision to halt support of Alpha NT at NT4 Service pack 6. I'd like to give you some of those clarifications ahead of general availability so you will have it "straight from the horse's mouth". First - your article "How Microsoft hedged its 64-bit Alpha NT bets" is factually correct about the timing of the web page updates, but the reason for the conflicting positions was just timing of updates. As reported by Joe Wilcox on CNET, Compaq was in Redmond on the 25th, informing Microsoft of our decision not to support productization of the 64 bit Windows products on Alpha. The version which said these products would be supported reflected Microsoft's best knowledge at the start of the day. Those stating that support would stop with NT4 SP6 reflected the updated position we provided them on the 25th. Simple but not a very sexy story. The story "MS trashes own 64-bit plans by killing Alpha NT" seems to be the popular press interpretation at the moment but again the real story is a lot less exciting. In particular: "It may be some time before we learn who really killed NT for Alpha, but it's the stray bullets that are likely to have hit 64-bit NT " Compaq placed an endpoint on our development of Alpha NT. It was our decision, made based on a number of good business reasons, foremost among them feedback from our customers. I'll go into the reasons for that in a moment, but Microsoft was not involved in the decision. They have worked hard to adjust their own product plans and communications in response to our decision, but it was Compaq who made the call. We also don't think any stray bullets will hit 64 bit NT development. This effort has from the beginning targeted a single codeline which would support both Alpha and IA64 architectures, as opposed to the 32 bit versions, which have substantially different code for the Intel and Alpha platforms. Much of the base level work to get the OS to a bootable state requires real hardware, and that work has been done on Alpha. Likewise, a demonstration of the value of 64 bit capability requires a real hardware platform. If current schedules hold, we may begin to see production-quality IA64 systems in 2000, and we would expect that development work would gradually transfer to those systems. But in the near term, and for a while to come, the primary development platform for this 64 bit work will continue to be Alpha. In addition, the availability of mature compilers and 64 bit applications such as the next generation Microsoft SQL products will help to rapidly verify design concepts and performance characteristics which continue to make Alpha a valuable development platform. Compaq has no intention of reducing the number of people or the level of hardware and infrastructure support we provide to Microsoft for this effort. We have met several times with the 64 bit development team to assure that we do not impact their ability to continue development. We intend to increase our investment in this development as the product moves closer to completion and the number of linked efforts, such as related Microsoft and third-party products, increases. You state "if Microsoft was trying to maintain linkage between 32-bit and 64-bit development, that the Alpha version of Win2k was a critical plank in the company's 64-bit plans". This is not only true, it is a central part of the development strategy. The 64 bit version is built on the Windows2000 codeline, and only those components which are 64-bit sensitive are unique to the 64 bit version. This implies that the primary Windows2000 code manages memory and pointers in a way which will be compatible with both 32 bit and 64 bit operations. This is a substantial benefit to the overall robustness of the code and positions Windows2000 for a long life as the industry transitions to 64 bit platforms. The technically inclined can look to the 64 bit SDK for more detail on this topic. In the next paragraph you say "One could loosely translate this as meaning that Compaq reckoned that Alpha was absolutely critical to 64-bit NT development, and that it could therefore pull the plugs on the old DEC NT joint development deal while carrying on with 64-bit development, maybe even getting some licensing revenue out of Microsoft while doing so." As described above, the availability of Alpha hardware is a great benefit in the 64 bit development, and will provide a robust OS solution more quickly than if Microsoft had to wait for production quality IA64 platforms. There was never any question that Compaq would continue to provide support for this work, and the 64 bit development effort was never linked to Alpha NT products in the marketplace. Compaq has never discussed with Microsoft the possibility of obtaining licensing revenue from Microsoft for our participation in the 64 bit development. Our benefit is in the in-depth understanding of the operating system, which translates into better integrated products for our customers and ISV partners and faster time to market for our platforms. Then you say "The Microsoft riposte itself is interesting, as are the circumstances of its release. The company announced it was cancelling development of future versions of 32-bit and 64-bit NT for Alpha, but also said that "Compaq, as well as our other OEM partners, will continue to work with us to deliver a 64-bit version of Windows for our enterprise customers based on the IA64 architecture." So although the two, er, allies are busily firing off salvoes at one another, they're both professing to be continuing with cosy joint development arrangements; they're just talking about developing two different things." I hope the paragraph above about our 64 bit development efforts with Microsoft clear up any misunderstandings about this. Clearly, there are other companies who are also working with Microsoft on 64 bit development, most prominently Intel and HP. Compaq is unique in being able to provide an early test bed with Alpha, but each partner has an important area of contribution. Compaq always intended to bring IA64 products to market which would host the 64 bit Windows products. The change over the last few weeks is that we are no longer planning to offer an Alpha product in that same market space. We have seen, from the strong performance and customer enthusiasm for our 8-way ProLiant servers, that these products are now able to compete in performance with the best of the RISC architectures. Customers have told us that they want a simplified product roadmap with clear segmentation around which products to use for which purposes. Our ISV partners have given us the same feedback. It is very expensive to develop two identical products for the same market space, but on two different architectures. This is one of the problems which plagued the database vendors in the Unix space a few years ago - the porting and verification work was greater than the core product development work. Both Compaq and its development partners would prefer to devote those resources to producing products which have greater capability and more robustness, and clearly, focusing on a single platform helps in that goal. Compaq wants to get the most efficient development environment for our ISV partners, for Microsoft, and for our customers. We intend to focus our efforts and resources around those areas where our customers and partners see the highest value going forward, and for Windows-based products those areas are the IA32 and IA64 architectures. "So what really happened? We can presume that the events of the week had been preceded by white-knuckle negotiations between the two companies. The Compaq move may have leaked early by accident or design, but in all probability Compaq wanted to force Microsoft to deal. Instead, Microsoft did something that might turn out to hurt it more than it hurts Compaq. By announcing it was pulling development completely, and suggesting that Compaq's strategy was to migrate users to Intel platforms it was to some extent undermining Alpha. But Compaq has been getting more enthusiastic about Linux and True64 on Alpha anyway, so the damage only applies to existing Alpha NT shops." This is just an unfortunate misreading of the statements of the two companies. I was a part of those discussions, and I can assure you that the only white knuckle portion of the trip was getting through the road construction on the way to the Microsoft campus. The possibilities and impact of this decision have been discussed for some time between the two companies. The exact timing of the decision and implementation of the product changes in the two companies as a result were accomplished over the last week. But there was never any significant tension around this discussion, just a facts-based analysis of how to minimize the impact on our joint customers and partners. The notion that Compaq surprised Microsoft, and that Microsoft retaliated with its product announcements, is just silly, although it plays to the current soap-opera atmosphere in the press. Microsoft made product roadmap adjustments necessitated by Compaq's product decisions, nothing more. They worked hard to analyze the impact and present alternatives at every point in the discussion. "If the Alpha platform really is vital to 64-bit NT development, Microsoft is probably also inflicting far greater damage on its own 64-bit development. Its immediate plans are for a stop-gap mixture of 32-bit and 64-bit code to support Merced, but Ballmer's promise of a 64-bit version based on the Win2k codebase is definitely receding." I described the development environment and plans in some detail above – but I guess I need to reinforce the fact that there has been NO CHANGE in the development plan, strategy, methodology or resourcing for 64 bit Windows. None. The only change we anticipate in the future is that we may have freed up some resources which can now be devoted to accelerating the schedules or enhancing the product. "The company will at least attempt to sync the development of the 64-bit product into these, but at the same time will have to pick up where the Compaq engineers left off, and probably disentangle itself from any Compaq intellectual property issues that are left lying around. Microsoft co-development deals, of course, generally leave Microsoft holding the IP, but there's no doubt still scope for the whole thing to go expensively legal. Delays? We confidently predict that not much will get out of the door until yet another new Microsoft OS roadmap is issued at WinHEC 2000." The Compaq engineers have not left off - Compaq will continue to provide the same or greater support than in the past. Microsoft is the owner of the intellectual property for its OS, and any work that Compaq does on the Microsoft product is covered under our existing development agreements. There has not been a single piece of legal paper regarding 64 bit development which will change as a result of our Alpha product decisions. I hope the statements above will help you to clarify some of the material you have published. I know "Compaq and Microsoft continue development efforts" is not as sexy as the headlines you have published, but the truth is often less exciting than a great work of fiction. I will be glad to route you to people within both organizations who can verify and extend the statements I have made here. If you have any questions please don't hesitate to ask. Jim Boak Director, Corporate Technical Strategy Compaq Computer Corporation

Next gen security for virtualised datacentres

More from The Register

next story
6 Obvious Reasons Why Facebook Will Ban This Article (Thank God)
Clampdown on clickbait ... and El Reg is OK with this
No, thank you. I will not code for the Caliphate
Some assignments, even the Bongster decline must
Caught red-handed: UK cops, PCSOs, specials behaving badly… on social media
No Mr Fuzz, don't ask a crime victim to be your pal on Facebook
Barnes & Noble: Swallow a Samsung Nook tablet, please ... pretty please
Novelslab finally on sale with ($199 - $20) price tag
Ballmer leaves Microsoft board to spend more time with his b-balls
From Clippy to Clippers: Hi, I see you're running an NBA team now ...
Banking apps: Handy, can grab all your money... and RIDDLED with coding flaws
Yep, that one place you'd hoped you wouldn't find 'em
Video of US journalist 'beheading' pulled from social media
Yanked footage featured British-accented attacker and US journo James Foley
Call of Duty daddy considers launching own movie studio
Activision Blizzard might like quality control of a CoD film
Primetime precrime? Minority Report TV series 'being developed'
I have to know. I have to find out what happened to my life
prev story

Whitepapers

A new approach to endpoint data protection
What is the best way to ensure comprehensive visibility, management, and control of information on both company-owned and employee-owned devices?
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Maximize storage efficiency across the enterprise
The HP StoreOnce backup solution offers highly flexible, centrally managed, and highly efficient data protection for any enterprise.
How modern custom applications can spur business growth
Learn how to create, deploy and manage custom applications without consuming or expanding the need for scarce, expensive IT resources.
Next gen security for virtualised datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.