Microsoft plans to deliver two specialized versions of its Windows operating system software for AMDs’ forthcoming 64-bit processors. Full announcement here.
Microsoft Announces Support for AMD Opteron and Athlon 64
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Why a specialized version? Won’t the current WinXP Home/Pro run on there? And why two of them as if Home and Pro weren’t confusing enough. Seriously, why not just put different kernels in the same package and autodetect during the install?
obviously programs can’t take advantage of x86-64 instruction set without releasing separate x86-64 compiled version, which is a huge hassle. plus what about ia64?
.net to the rescue
thanks to .net, developers can make one build of program, and it will auto optimize for ia32, ia64, or x86-64. it won’t be horribly, painfully slow like java, and it won’t be ugly because it uses windows forms and works just like any other windows application! plus every new version of window will come with .net framework. windows comes with crappy version of java, but will always have latest greatest .net framework.
is it fare to users to have java shoved down there throats by ignorant java zealots? programming in .net is what microsoft would have u do, and they control windows. because of this, .net application are portable to 97% of computer in the world. sure java is a little more portable, more like 99%, but who cares about 2% if it make u application ugly and slow
Maybe specialized was not a good word that C|Net used. But yes, it is just WinXP Home/PRO, just on 64bit.
XP Home and Pro are not confusing. Pro has some more fs features, support for SMP, and more memory support I think.
.net to the rescue?
Only for end user programs, MSFT will still need to release a native version of Windows to run on the system.
Just Trolling…
They could put both kernels in the same box; except, just having differnet kernels wouldn’t give you the best performance. ie: .net wouldn’t be 64bit aware.
Some people have seen a 30% speed increase by just recompiling for the new chips. MSFT is most likely going to include the 64bit APIs in this version and are just re-using 64bit ports for the reset of the system for use with IA64. And that would require them to put more CDs into the box to handle having 2 versions of most of the system. It’s better to have a special box that’ll be 30%+ faster then the standard version; then to have 1 box with only a modified kernel thats < 30% faster (if only the kernal is different, then no supporting code is affected like drivers, system utilities, .NET, …).
It will be interesting to see how the mono project comes along. If they can port their stuff to PPC, MIPs, Dragon, ia64, ia32, x86-64, Sparc, etc. Then I bet they have more of a chance at competing with .net than java.
And what kinda of freak would take a kernel that supports SMP and remove it from the Home edition of the software? I have a SMP system running at Home. But to make use of it I have to fork over the extra cash for the “Pro” version? Fuck you very much Microsoft.
Three years ago, Microsoft was suppose to release Windows 2000 for the Itanium (AKA 64-Bit CPU) However versions of Windows for Itanium have been slow and don’t work real well. It’s rather strange that Microsoft would go with AMD since Microsoft and Intel are partners. More power to them though.
i find myself wondering whether the strains of running Windows on two distinct processor families was part of the reason for Microsofts purchase of connectix’ emulation technology.
could they be planning virtual A64 and IA64 machies to allow cross-compatibility of software?
> However versions of Windows for Itanium have been
> slow and don’t work real well
Because NT is badly designed (not in his first implentation, but the current one) and not really portable… you’ll see this new implentation will be a crap one…
“However versions of Windows for Itanium have been
slow and don’t work real well [???]…Because NT is badly designed (not in his first implentation, but the current one) and not really portable… you’ll see this new implentation will be a crap one…”
I guess that is why we see Windows capturing the top benchmark records everywhere, like this one (on 32-way systems)…
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=no…
> I guess that is why we see Windows capturing the top
> benchmark records everywhere, like this one (on 32-way
> systems)…
Yes on intel system we saw performance… but other than that… beurk…
“Yes on intel system we saw performance… but other than that… beurk…”
Note: That chart I linked to shows (pre-release) Windows 2003 on IA64, not IA32, getting kick-ass non-clustered TPC-C results.
The port from IA32 to IA64 was probably a much, much bigger effort than the port to AMD64 will be (the native IA64 instruction set is totally new, remember), and all indications are that they seem to have pulled that one off just fine. I don’t see why the AMD64 port should pose any kind of a problem but I guess we’ll just have to wait and see when it comes out.
Yes, it probably is. NT is probably riddled with ia32 specific asm optomization by now with no (or buggy) c code to back them up.
If you are trying to cut corners performance can be captured at the expense of portability. This would explain why MS favors x86-64 as it won’t break (or worse run slowly) the asm optomization.
nnooiissee: NT is probably riddled with ia32 specific asm optomization by now with no (or buggy) c code to back them up.
Up until Win2k we had Windows NT running on Alpha, PPC and x86 and there was seemingly very little problems coming out with concurrent releases which (as well as several interviews) should tell you that the NT kernel is most likely very portable with processor architectural specific parts separated into modules. Since the Itanium was long way coming before MS decided to drop Alpha and PPC for Win2k they prolly knew they’d be stupid if they would have removed the portability from the kernel as well as being monumentally stupid if something drastic were to happed such as a completely new CPU arcitecture coming out and take over the market. MS haven’t been know for putting all their eggs in one basket in the past so why should they have done that in this case?
Now porting an OS from 32 to 64 bit is quite an task as not just the kernel needs to be modified but userland and drivers as well. Making sure that userland and drivers are 64bit “adjusted” is probably even a bigger task than porting the kernel to 64bit and that is where I guess most work is being put down.
The asm for x86 is very similar – in fact most assembler will run pretty much as is once you update all registers used for addressing to 64 bits. However do some research on 64 bit windows for x86-64. While I haven’t seen a windows 64 system yet, it would appear that the Win32 API is much the same as before – even the same dll names – someone with a beta copy confirmed this for me. There is a major difference though and that is they are using amd64 fastcall rather than stdcall for the win32 api which looks to be a lot faster. Also if you check out the x86-64 development notes, it seems clear that embedded assembler will not be available in the MS VC++ compiler. Given this and NT’s history, I very much doubt that there is much x86 assembler left in the kernel. (don’t also forget the Dec Alpha ports as well).
BTW, my kernel (Petros) has a bit of embedded assembler but it was a piece of cake to translate this to x86-64. The hardest thing to upgrade was the paging. Dealing with a 4 level page structure required a rethink of how things were done. Also, my kernel can run 32 bit and 64 bit executables side by side without a thunking layer being required like the Win64 does. Hope to get a beta out by the time of the Opteron release.
P