Slashdot Mirror
Windows XP-64 Delayed Into 2005
vincecate writes "Although
Windows XP on AMD64 was demoed at ComDex in 2002,
Microsoft is now
delaying the release till the first half of 2005.
Given Microsoft's history on this product, it could be
even more than a year before it is really released.
At least
one person at Intel says they did not ask Microsoft to delay
the release.
In any case, for the near future if you want to run a 64 bit operating
system you will either be using
one of the free Linux versions
or the
free download of Windows XP-64 beta.
Though Sun started well after Microsoft, they are
progressing well on their Solaris port to AMD64 and could well release earlier."
"In any case, for the near future if you want to run a 64 bit operating system you will either be using one of the free Linux versions"
There are supported linux versions available as well. I know Red Hat and SuSE have released versions supporting the amd64 and I think Mandrake does as well
In any case, for the near future if you want to run a 64 bit operating system you will either be using one of the free Linux versions or the free download of Windows XP-64 beta.
Um, what about Mac OS X?
Find me in ~/.sig
Besides Linux and Windows, you can also use FreeBSD, for which amd64 is in tier 1 (full support), along with i386. Other BSDs of course support it :
NetBSD
OpenBSD
Mac OSX 10.3.4 does not run in 64-bit mode on my G5.
You might have noticed that there are other 64 bit CPU's than AMD64 that are in wide use, and other OS than Linux suports AMD64.
FreeBSD supports AMD64, and so does NetBSD.
Also OpenBSD supports it, but the support is even better in current. In addition, OpenBSD will use the NX-bit to increase security.
Uh, you are wrong. For the early XBox 2 dev kits, Microsoft has a version of the NT kernel running on a slightly modified G5 system. Not an x86 architecture there.
Hmm, why is this modded as Informative? Windows NT ran on MIPS (I've seen it running on modified SGI Indy boxes), PowerPC, Alpha and x86. The HAL makes it possible. Windows 2000 Beta was running on Alpha. What makes you think Windows is an x86-only product?
Mike Bouma
Or get an Ultra 5 off eBay for $50.
10.4 Tiger will be the first 64bit OSX release. However iirc there will also be a 32bit kernel on the cd to allow people with G3 and G4 systems to be able to run 10.4
While you're right, Windows definitely was available for a variety of architectures, unfortunately there was a _serious_ shortage of software for Windows NT for PPC, MIPS and Alpha/AXP. A few Microsoft packages, like BackOffice, Visual C++, and a few other things, were available; most third-party software, however, was not ever built for anything but x86. The only reason the Alpha/AXP version had a longer lifetime, and apparently more software, was due to the FX!32 dynamic translation software that Digital developers created to run x86 binaries on Alpha. There was no real technical limitation to speak of, just momentum of Windows on x86.
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
Yes, as soon as Tiger is released, you'll be correct. The current OS X release, however, is not 64-bit native.
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
Windows NT wasn't originally designed for x86. Hell, initially it was developed for a CPU that didn't even exist - when it was first being developed, it was targeted at Intel's i960 RISC architecture. However, because the i960 RISC chip was plagued with delays, it was ported to another architecture (I believe the first one was MIPS32). Dave Cutler's clean OS design (one of the major designers of DEC's VMS operating system, hired away by Microsoft) made this possible relatively quickly.
And by the way, the original NT moniker was actually a reference to the CPU simulator - named N-Ten - that the first i960-native builds of what became Windows NT ran on.
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
WOW64, if you're not familiar with the acronym, means windows on windows 64. It's basically their "emulator" (it's more of an interpreter) to run code not compiled for 64 bit. Instead of going the FreeBSD route and allowing for both 32 and 64 bit programs to run at the same time (props for freebsd), Microsoft decided to go with an emulator - which happens to suck horribly, and freeze alot.
Lies.
Windows and FreeBSD both do exactly the same thing, which is to let 32-bit programs run at full-speed, natively, on the cpu. Practically the whole point of AMD64 architecture is backwards compatibility. The world didn't need another Itanium.
WOW64 Implementation Details
I hate being a pedant, but it was definitely a tad more than re-compiling the source with a new Gee-See-See.
You're right though - considering the number of both 32 and 64-bit ports of the linux kernel, targeting amd-64 was just about filling in the missing pieces.
If you hunt around the linux source tree, you will find this asm/generic stuff, which is an implementation in C of the stuff that should really be done in the architecure's assembly (cause that would be faster/efficient). Thats the stuff they use for new ports until the write they native versions of those algorithms.
Urrr, MS have been saying that they'll offer free upgrades from XP to XP64 for people that want it.
So, compare free WinXP64 to waiting ad infinitum for Longhorn.
Curious that no one mentions the stability of current x86-64 Linux implementations. I'm running one (SuSE 9.1) and it's very disappointing. Binary software doesn't recognize the processor type and browser plugins don't work. 32 bit browsers would fix that but they are unstable for me. In fact, firefox in any form locks my machine consistently. I certainly wouldn't use the machine for any critical work though most things seem fine.
Any user of a 64 bit x86 system should expect all 32 bit applications for that system to "just work". That's certainly not the case for linux and I expect Microsoft has a much higher standard in that regard.
and yes, it looks rather attractive, as usual.
Yes, this looks like flamebait, but I'm actually surprised that it's taking MS this long, considering the resources they can throw at any given problem.
MS historically is not that good at portability. NT on powerpc, alpha, mips(maybe) failed. MS apps are not like *nix apps where most of them are designed from the ground up to be portable across platforms, including different byte ordering and default word sizes. Linux and the BSDs have this in their OS _and_ in their apps. Even if MS were to have a working version of XP for 64bit platforms, there would be no apps for it.
One thing that kills me are the MS macros/typedefs for working in their system. For example, the DWORD (unsigned long, 4 bytes) means "double word" which is left over from the 16bit days (2x 2 bytes). However, on most 32bit systems an int and a long are the same size (4 bytes each), on 16bit systems they are 2 bytes and 4 bytes respecively, and on 64bit systems they are 4 and 8 bytes respectively. People run into problems when they are expecting a DWORD == pointer size, and so on.
One of MS's strong points is its backwards compatability, one of Linux and other unixlike things (including solaris) is that they are forward compatable.
MS has got some work to do to play in a heterogenious world (read not IA32).
You are the kind of person I was talking about when I wrote the article about the bridge dwellers in the article linked as 'one person at Intel....'. Read it, there really is no conspiracy.
-Charlie
In fact, for functions that don't need 64 bitness, 32 bit mode is preferable on the G5. 64 bit mode will actually be a little bit slower for code that doesn't require it.
Like you said, lots of people get confused by x86-64 bringing such a performance jump, but that's because x86-64 brings some major additions to the architechture. With the G5, 64 bitness mearly means it can natively do 64 bit math.
Most of the problems are SP2 related. MS decided to base Win iAMD64 off of XP SP2, and SP2 is having 'issues'. From what I hear, they are pulling people in to get it out the door, and those people are mainly coming from Longhorn.
They are taking security seriously, but they are realizing exactly how impossible it is to do what they announced, IE lock things down. The deeper they dig, the more problems they find. The more they find, the more people they pull in.
People tell me that it is a quagmire of monumental proportions. Golly, who would have guessed.
-Charlie
(I write for the Inq, and I talk to people, this is more than idle speculation)
As I posted above, I wrote the Inq piece that is one of the links in the main story. Unlike you, I went and asked the players on both sides, very high up players. They contradict what you are implying.
/. speculating.
Now, who do you believe, high ups at AMD AND Intel, with a couple of Microsofties thrown in for color, or an anonymous person on
There was a reason I wrote the article, it was to keep posts like this from coming up every few hours. I now see my fatal mistake was assuming the trolls can read.
-Charlie
Sorry, wrong digit. The i960 is (and has always been) an embedded processor. I was designing stuff with them in the early 90s, and they are still used in some RAID controllers and the like.
NT was actually prototyped on the Intel i860 processor - I know as I used to work for MS and have seen some of the original dev kit (co-processor boards that plugged into another system). But once it was obvious that the i860 was not going to be the 'next great thing' from Intel, they switched to x86.
Win32s, for example was a porting layer to run a subset (hence the s) of the Win32 32-bit APIs on Win16 Operating Systems. (0% 32-bit by definition)
Windows 95 was a 32-bit OS with 16-bit loadable sections for backward compatibility. If you didn't run 16-bit drivers or apps, you didn't have 16-bit.
The Windows NT family (Windows NT, Windows 2000, Windows XP, Windows Server 2003) were written from the start as 32-bit/64-bit hybrids with their architecture at 64-bit and their APIs and implementation ported down to 32-bit.
Oh, and OS/2 was originally a 16-bit OS and was gradually ported to 32-bit starting with 3.x.(Perhaps you never bothered to look at OS/2 1.x or 2.x which didn't even support the 386 extensions to the intel 16-bit architecture but my guess is that you never really used OS/2 but just heard it wasn't a MS OS so it's really kewl to discuss it, d00d)
Windows NT (and family) have shipped in x86, Alpha, Clipper, PowerPC and were ported to several other chips as tests.
It's also worth noting that the Windows API is NOT native to the Windows NT family and another API could be dropped in as needed. Early versions shipped with OS/2 and Posix.1 native support as well as Win32. (And, no, these are not emulators or porting layers on top of a native API, they're just as native as Win32)