Slashdot Mirror
Microsoft To Dump 32-Bit After Vista
SlinkySausage writes "Microsoft has used its annual hardware engineering conference to announce that Windows Vista and Server 2008 will be the last versions of Windows capable of booting on 32-bit CPUs such as Intel Pentium 4 and Core Duo. AMD, which introduced 64-bit CPUs early — much to the derision of Intel, which said there was no use for them at the time — must be delighted with Microsoft's decision. Owners of first-generation Intel Macs that used (32-bit only) Core Duo CPUs may not be so happy knowing that Vista will be the last Windows they will be able to run."
Linux, *BSP, etc, etc, are happy to support 32-Bit/64-Bit at the same time. I tried out the 64-Bit version of Windows Vista in VMWare (which can run 64-Bit Vista on top of 32-Bit Vista) and the only "benefit" I got was that my old 16-Bit apps stopped running. (Got several great 16-Bit games, and a 16-Bit dictionary.) What can the newfangled 64-Bit future Windows do that won't be feasible with a 32-Bit version lurking around?
As a programmer I've been waiting for this. I was actually disappointed that Vista would support 32-bit CPUs, but I guess there was no way around that, given how common 32-bit x86s still are. Having one architecture to support will make things much easier, as well as get people to actually update their legacy code. Now if MS could get them to actually fix all the problems due to generally crappy code (like requiring admin)...
You have tried to support your argument with faulty reasoning! Go directly to jail; do not pass Go, do not collect $200!
The 4GB memory barrier is fast-aproaching for high-end users, and dealing with it is a MESS. Most motherboards don't support PAE (either due to lack of re-mappable PCI address space, or even lack of 36-bit address lines!), so we have a hard-limit of 2-3GB in the most popular version of Vista (32-bit). This is going to be a rough few years for game developers.
I really don't see why Microsoft went 32-bit on this version anyway...I'd say over %80 of the potential upgrade platforms and over %95 of all shipping PCs today support x86-64 mode. But when you look back, history paves the way:
Windows 386 = Windows 2.0 with 32-bit enhancements bolted-on. Equivilant of Windows XP 64
Windows 3 = crossover version with support for 16-bit and 32-bit processors. Equivilant of Vista.
Windows 95 = supports only 32-bit processors. Equivilant to the next revision of Windows.
Too bad Microsoft didn't have the balls to jump the gun and make Vista 64-bit only.
Man is the animal that laughs.
And occasionally whores for Karma.
Actually, what I thought was crazy is that Apple customers aren't the only ones using the Core processors, why single them out? Is Apple even the largest customer of Intel 32-bit processors?
Apparently because on Slashdot, making some sort of backhanded Apple comment at the end of every story guarantees a lot of comments.
I thought it was a total non sequitur, too. Apple users will be upset? How about all the people who can't reboot into OS X and go on their merry way? I think they're going to be a bit more pissed.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
No, but it will increase the amount on my hydro bill when I build a cluster of "obsolete" 32-bit processors in the basement
Just because Microsoft gives up on something, doesn't mean everyone else has to. Just look at Vista, it was more exciting when it was still vaporware. Even people buying new Vista-ready PCs still prefer XP, because Vista does hardly anything new, certainly nothing better. Microsoft should have released a new Theme pack for XP instead. I'm sticking witn XP for as long as I can, despite having a perfectly fast dual-core with gobs of ram and a beast of a graphics card. I didn't buy all that nice kit to waste all its power on a filesystem and mouse driver... I spent the cash to do video processing, rendering and GAMING! Anything that takes power away from those primary activities is a bad thing. That's why I like Linux because I can make it as lean as I want to squeeze out a few extra cycles.
If I wanted a pretty OS, I'd buy a Mac. They manage the slick graphics without the outlandish hardware requirements, and they can actually do two things at once without both processes stuttering.
-Billco, Fnarg.com
The hardware VT bit is a bit misleading. Some instructions are slower under Intel's VT instruction set than under software emulation or native virtualization. However some instructions are faster. A virtualization company who tests these things will be able to utilize some of the hardware VT to gain an edge.
Regardless, VMWare uses native virtualization in all of its products, meaning it still needs to be run on the same type of CPU. It runs the instructions directly on the CPU, so the switch to Intel was still important. Virtual PC for the Mac uses emulation, which is much slower.
Of course, being able to boot Windows is certainly a factor, too. Before Boot Camp, though, it was probably beyond the capabilities of most people.
Since I've been itching to try out the new Charts feature on Google Spreadsheets anyway, I threw together a spreadsheet of the Windows memory requirements:
2 Avkn0zhNfTcQ
http://spreadsheets.google.com/ccc?key=pdgLUlhjY2
If that isn't a hockey stick chart, I don't know what is.
BTW, does anyone know how to get the labels to show up correctly?
Javascript + Nintendo DSi = DSiCade
Let's hope that when 128-bit machines come out, gcc makes its ints have the same width as the pointer.
The number of programs that break on compiling for 64-bit because of the retro 32-bit ints is just plain ridiculous. Sure, I agree, that's because they weren't written very well in the first place, but you can't expect to fix everyone's old programs when recompiling code to larger architectures. That doesn't scale.
That was a *very* poor decision by gcc designers, and unnecessary. The "natural" size of an integer register on any given architecture (which is 64-bit on both Intel and AMD 64-bit architectures) should also be the size chosen for gcc's int.
Beginning with Solaris 10, 32-bit Hardware is no longer supported on SPARC.
The operating system still ships with support to run 32-bit applications.
Microsoft will certainly never be a serious contender in the tiers of
professional computing filled by Sun and IBM and I know you can argue that
with me for arguments sake but after everything is said and done it is
still IBM Mainframe/AIX muscle and Sun Solaris tendon that make the world
go around. And as far as rotating the globe goes, Microsoft excels of course at
marketing spin so while the major players all abandoned 32-bit more or less
quietly one wonders how Microsoft will flaunt and celebrate the fact in
front of a impressionable lay public.
Actually, last time I checked modern 64-bit cpus could actually only address 2^40 bytes of Ram, because you couldn't physically attach that much ram to them. 2^39 starting at 0 and 2^39 at the other end of the 64-bit spectrum.
Essentially the upper half IS reserved for the OS (which is much more than 2^48, it's 2^63), but it will be a long while before it's a problem, because at the moment there's a big no-man's-land between the valid program and OS memory addresses.
They're not *my* recommended requirements. They're pulled from the source pages. (check the column on the right of the first sheet) Those pages appear to pull from the requirements that Microsoft published. I don't know if you remember back in the old days, but Microsoft tended to lowball their memory requirements. (Presumably to sell more copies.)
If you've got a reliable source that gives different values for these features, please share and I'll update the sheet.
Javascript + Nintendo DSi = DSiCade
In order for a vendor to provide Microsoft approved "Certified for Vista" drivers, the company also has to release an x64 version of the driver.
Go get yourself a Mac with a Core 2 Duo processor and see for yourself.
It is not necessary for the kernel to be 64-bit to support 64-bit executables in user space. It is only necessary for the kernel to know how to manage an MMU that supports 64-bit addressing and for the kernel to maintain all unmapped user-space addresses as 64-bit values. Once mapped into the kernel, the kernel-space representation can safely be a 32-bit value without limiting anything other than the maximum aperture within a 64-bit app that the kernel can directly examine/modify at any one time.
No special hardware is necessary to do this. The Mac OS X kernel does not use any 64-bit instructions; the same kernel is used for both 64-bit-capable Core 2 Duo CPUs and 32-bit-only Core Duo CPUs. It probably has a few lines of special-cased assembly language at the system call interface layer and the pmap layer (where memory mappings are stored into the MMU) to access the upper halves of registers, so for a dozen instructions per system call, it might be running in 64-bit mode (on x86---on PowerPC, it doesn't even do that, AFAIK), but the kernel as a whole does not run in 64-bit mode.
If you think back to your Operating Systems class, you'll recall that memory management never really uses pointers. At worst, it uses things that look like pointers but aren't really used as such. Ideally, though, a well-written memory management subsystem just uses integers (or equivalent opaque types). Pointers in a user-space application have no meaning in the kernel. Those user-space addresses generally point to entirely different physical addresses in the kernel unless you get really lucky. Thus as far as the kernel is concerned, they are just numbers. It really doesn't matter whether those numbers are 32 bits in length or 64 bits. As far as the kernel is concerned, it's just a uint64_t or equivalent, which allows for 64-bit numerical computation even on 32-bit CPUs. As long as the kernel doesn't do something careless and truncate it to a 32-bit value, the kernel doesn't care about how long the value is.
Similarly, physical addresses in RAM are meaningless to the kernel. They are just numbers. As long as the kernel is careful not to truncate those numbers to 32-bit values, it doesn't matter how long they are. The only thing that needs to understand the longer value is the MMU, and of course, it does. All the kernel cares about is that the page 0x000423847362739a maps onto address 0x00341ac0 in the 32-bit kernel address space and also maps onto address 0x000001c538273847 in a user-space process with a 64-bit address space. Those are just numbers that get plugged into the MMU, and it does all the work.
I could probably implement a kernel that supports 64-bit user space processes with an 8-bit kernel address space if any 64-bit CPU still supported 8-bit addressing. The biggest problem would be finding room in an 8-bit address space to map the page table for a 64-bit process; it might be kind of tight. In theory, though, you could do it. The point is that for 64-bit executable support, the only real requirement is the ability to perform 64-bit math, which can be (and is) easily emulated using a small number of 32-bit math instructions.
There are exceptions to this, of course. The Linux kernel, for example, historically divided a 4GB address space between user-space apps and the kernel and ensures that the two address spaces do not overlap. There are performance advantages to doing that because you can leave mappings in place during boundary crossing. However, such an layout won't allow 64-bit processes on a 32-bit kernel unless you do some really weird lower-4GB bounce buffer tricks on every system call (at a huge performance loss). It's a feature vs. performance tradeoff, really. I think that Linux has pretty much stopped doing that at this point, but I'm not certain.
Mac OS X does not do a split address space. The kernel has a full 4GB address spa
Check out my sci-fi/humor trilogy at PatriotsBooks.