Slashdot Mirror
OEM Windows 7 License Sales End This Friday
colinneagle writes This Friday is Halloween, but if you try to buy a PC with Windows 7 pre-loaded after that, you're going to get a rock instead of a treat. Microsoft will stop selling Windows 7 licenses to OEMs after this Friday and you will only be able to buy a machine with Windows 8.1. The good news is that business/enterprise customers will still be able to order PCs 'downgraded' to Windows 7 Professional. Microsoft has not set an end date for when it will cut off Windows 7 Professional to OEMs, but it will likely be a while. This all fits in with typical Microsoft timing. Microsoft usually pulls OEM supply of an OS a year after it removes it from retail. Microsoft cut off the retail supply of Windows 7 in October of last year, although some retailers still have some remaining stock left. If the analytics from Steam are any indicator, Windows 8 is slowly working its way into the American public, but mostly as a Windows XP replacement. Windows 7, both 32-bit and 64-bit, account for 59% of their user base. Windows 8 and 8.1 account for 28%, while XP has dwindled to 4%.
Well we can start with the memory limit. I'd only be able to use 1/4 of the RAM in my laptop if I had the 32 bit edition of Win7.
Sauce: http://msdn.microsoft.com/en-c...
(Not OP)
Actually, to me, a "Windows 7 with slightly worse UI" is an understatement. If Windows 7 never existed, I would still be running Windows XP, maybe forced into Vista to keep my system secure.
As much as it is off-topic, I do swing both ways.
As someone who has investigated what the compiler (.NET) does on a 64-bit machine I can answer your questions somewhat:
Are the 64 bit registers and arithmetic used often, or would that have more of a scientific number crunching (corporate) application than anything else?
Yes. The original registers were ax, bx, cx, dx, si (code pointer), di (data pointer), bp (byte pointer), sp (stack pointer). As you can see, there are only 4 values that you can hold at once. And cx and dx have special meanings in some commands, so only a and b are really free. This means that if you have even 3-4 local variables, most likely one or more are being stored on the heap. 32-bit doubled the size of all of these, but you were still basically severely limited to 2-3 registers at a time for actual programmer usage.
64-bit adds 8 more free and open registers (r8-r15). These can be filled with anything meaning that any subroutine that has local variables that go out of scope quickly most likely doesn't actually store these values on the heap at all anymore. This means that there is no memory access at all, which leads to much faster code.
32-bit goes up to 2 billion, so 64-bit math is rarely used for integers. But 64-bit floats are very common. And floating point math is much faster. Also, there are extensions for math like MMX, 3DNow!, SSE, SIMD, etc., all of which also have their own registers. And now people are using graphic cards to do really fast math sometimes as well.
Or can they sometimes cram two 32 bit numbers in a register and process a 32-bit program twice as fast?
You can, but with so many registers available now, there's usually no reason to so it rarely happens.
I assume that that 64-bit opens up a lot of extra room for processor commands. Do they use more commands making bitcode more succinct and faster?
All the new processor commands are called: MMX, 3DNow!, SSE, SIMD, etc.
It's not so much that the new commands make things more succinct, they just do more in hardware. For instance, if you have ever zipped anything, you have probably seen the CRC32 checksum that goes along with each compressed file. Well, that's now a command in SSE4.2. So you can have the CPU do CRC32 for you and it's 10-times (or more) faster than doing it in hardware. It's just a matter of whether, for instance, WinZip, 7-Zip, Explorer or whoever actually rewrites their code to use this CPU command. (And whether you downloaded a new version since they did this.)
Similarly, it's not a matter of whether a programmer knows about these commands, because these days most people write in Java or C#. It's a matter of whether the .NET or Java compiler gurus that turn the IL into assembly with on-the-fly compilation on your machine know about all these new commands. Since there is no CRC32 command in .NET, that command will never be used by most normal people, even if they are using CRC32's, because the Just-In-Time compiler can't tell that that's what their subroutine is doing.
And of course it would make them quicker to execute as more data can be crammed into a single word (The Word length would go up to match the number of bits, I assume. I think I remember working with 32 bit words in univ, so that makes sense)?
Actually, strings are a hair slower in 64-bit because they are usually UTF-8 or UTF-16 so characters are a little more inefficient to work with. I'm really not sure why there aren't new CPU instructions for the most common string functions for the most common string types. Maybe somebody can get on that. But I guess that most string handling is so efficient already that nobody notices that much.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
Actually, it just works in chrome these days.