Username or EmailPassword
...except of course, if your CPU doesn't support x86_64 instructions, like Intel's Atom. It's a shame really, and I'm hopeful the next Atom version will have 64-bit support included.
I'm hoping so too...whether I like it or not, I keep ending up in the Windows environment, and sooner or later they're going to stop making 32-bit versions of their OS.
Uhm... Last time I checked the Atom is an EM64T processor fully capable of running x64 versions of windows - I have one here running XP x64 just fine as well as a AMD64 build of Ubuntu, so what exactly are you saying?
Some chipsets -- especially some mobile chipsets -- do not support the x86-64, even when the processor does. Also, on some motherboards with x86-64 chipsets the motherboard traces aren't connected for 64-bit addressing. That's likely the cause of the confusion.
Anyone who wants more info can read here:
(Look under the "WORKAROUND" section.)
Not the mobile versions, sadly, like Thom pointed out. :-(
I quite like the x64 experience and after having convinced a few people to take the plunge they keep thanking me for it everyday. The only gripe for me was drivers but XP x64 is chugging along great for me. I just need a vpn client and then I would be set.
I'm not trying to be rude or anything, but why did you even bother to convince people to go 64 bit? Unless you need the memory why does it even matter? It seems like you set yourself up for headaches and the benefit is not much for most people.
Well, beyond the memory benefit, 32-bit operating systems are going to be phased out at some point. Last time I checked, Windows 2008 was supposed to be the version of server OS running 32-bit.
No argument there, but why run 64 bit now, when there are these headaches?
I tried it with linux for a while before I realized it was a waste of time for me. I never bothered with 64 bit xp or vista.
You're right, there are some people who don't need to go 32-bit, and could probably stay that way for several more years.
In my case, and in the case of anyone who's building large-scale apps, the extra memory is a life-saver.
In another case, there are applications (like Microsoft Exchange 2007) that are being released as 64-bit only applications. That's definitely a minor occurrence, but I had to help someone out with that exact situation.
Interesting. I was just curious if I was missing out on something as my needs don't really dictate that I run a 64 bit OS. There are times when the extra memory would be nice (running multiple OSs in vmware), but I've been coping.
I will reply by saying most of my friends have over 4 gb ram. They do video editing, (hd footage), lots of gaming, are java developers etc etc. Whenever I do any sort of development using enterprise oracle products, I can easily use up 2.5 gb of memory. If I was using 32 bit, well that does not leave me with much headroom. And if I am bored, I just stop doing some work and turn on some Crysis without having to turn off any of the software.
My brother who is editing HD footage is already consuming over 4 gb of ram and now he has to go and grab 4 more gb to not cause any sort of disk swapping.
Also as far as I understand, 64 bit processes all have DEP enabled by default. No ifs ands or buts so in terms of security its a good idea.
And also before building machines, we do our research to see what works and does not work. So it just works for us and we are quite happy. No offense taken from all the people who asked why. Main thing was memory usage, server based OS and didnt want to upgrade to Vista. Its just a win win situation fellas.
I am in the same situation. A year ago, I installed Vista x64 on a high-end computer and I didn't feel any difference in terms of speed because basically, I use only Opera, Adobe Reader and MS Office.
However, in the case of David, it's different because he is dealing with servers that can need a lot of memory in some cases. High-end servers can be dramatically relieved with the extra memory unleashed by the x64 architecture.
But unless we are forced to migrate to x64, I don't see any compelling reason to migrate to x64 on the desktop for regular users who don't use professional applications (CAD, 3D, audio, video).
I'm surprised that this didn't make the list:
"The default Internet Explorer is 32-bit"
The 64-bit IE is there, but buried in a sub-menu of the Start Menu. You may not think this is important, but it actually severely hampers the porting of any plug-ins (Flash, Java, Adobe Reader etc.) to the 64-bit platform because lazy-backsided vendors will claim "we don't need a 64-bit plug-in because no-one ever runs 64-bit IE".
A vicious cycle of course - no-one runs 64-bit IE because there's no 64-bit plug-ins (and it's buried in a sub-menu) and so on and so on. Sadly, Adobe in particular are criminal with their abject lack of 64-bit support of any of the platforms for virtually anything they write. Shame on them!
Bemusingly, the best platform to run 64-bit apps in the many, many years since the Athlon 64 came out is actually Linux - which has far, far more 64-bit apps than the Windows platform (and becaose of that, I suspect a much higher percentage of Linux users run 64-bit than the percentage of Windows users that run 64-bit).
32-bit browser plugins are a pain on linux too.
At work I have a Centos desktop (so not that bleeding edge), running 64-bit Firefox on which I installed (had to) 32-bit flash9 and nspluginwrapper. The setup is pretty easy and straightforward.
nspluginwrapper is messy with 64bit, some people have no issues, but many have crash after crash. Although I have gotten things moving along, my 64 bit experience on linux has been far more frustrating than in windows, especially in the browser plug in respect.
is there a horseshoe and rabbits foot by your computer by chance.
Its weird and from the plethora of posts ive gone through on forums, I know im not alone on this. luckily my need to use it is far and few between, but usually when I have it working, an update somewhere inevitably trashes it and im back to square one.
Looking back, you're right, I should have put that in the list.
Since it wasn't as frustrating as the ODBC Administrator issue, that's probably why it didn't make the cut.
Does a 64 bit browser make any sense? You need more than 4 GB of memory to run your browser?
Would mod that up if i could, 64bit is important for kernels and apps that need to address an insane amount of ram, and thats about it.
The paragraph about memory limits is a bit misleading. In 32bit address space you can reference up to 2^32 addresses, or 4 GB of RAM. If your OS limits your app to a lower ceiling, that's another problem.
As the 16.8 million TB of 64bit registers seems an awful lot, most consumer-grade 64bit-CPUs also have a built-in limit of how much memory they can really address. What's important is the width of the address bus. In AMD X2 CPUs this used to be limited to 40bit, upgraded to 48bit with the X4.
That's not an accurate way of describing what goes on. Given chipset support, you can simply map the extra memory 'covered' by the video card to a physical address higher than 4GB. There's no swapping involved. Windows does not enable this feature for client SKUs since video and audio drivers tended to barf on a 32-bit system when given a physical address bigger than 32 bits.
User mode processes get 2GB of virtual space by default. I'm curious about why this is limited to 800MB for IIS, but swapping is not involved at all regardless of the reason.
I'm guessing this is the problem.
With some help here:
Imagine you have two processes on an x86 machine. Each one gets 2 GB of private virtual address space. Let's say that each one is using 1.5 GB of space. Let's also assume that the kernel is caching 2 GB of file-backed data in the file cache. You've now got 5 GB of physical memory consumed.
One thing to note here, is that you don't have to have memory mapped into the user or kernel virtual address space for it to be used as cache... the Windows Memory Manager will happily keep cache pages around and keep track of them without consuming any of the 32-bit address space (except for some small control structures).
Even if you ignore the file mapping thing, each process gets 2 GB of address space and you already have to swap between them when you switch to a thread of a different process, so if you open four 1 GB images in 4 instances of Photoshop, you can consume 4 GB of RAM on a 32-bit system (assuming you had an Advanced Edition of Windows Server).
The reason this wasn't allowed on Client SKUs was that if you tried to use the typical GPU driver in this situation, the system would barf when the physical addresses are truncated by the driver and passed to the hardware.
Incidentally, the PAE-enabled Windows Server kernels do not support nearly as much memory as the 32-bit hardware with PAE supports because the per-physical-page descriptors begin to take up a whole lot of space and these have to reside in mapped virtual memory. I think the capped limit is no more than 900MB worth of these PFN entries (at 28 bytes per page, that's 32GB of physical memory supported).
Virtual memory is a lot more subtle than you think it is.
"Microsoft.NET applications may be able to run in 64-bit mode automatically"
I somehow doubt this. Executable files have a Machine type value in their header. This tells Windows what architecture that file was made for. If you try and run an AMD64 file on a 32 bit Windows build, you'll get an error stating it's not a Win32 executable.
While I haven't read the background on WOW64, I doubt it makes an exception when it comes to .NET applications.
A .NET application is a normal windows application that imediatelly calls the .NET framework. While Windows could in theory have exceptions in place, that would make it very unflexible and modifications to this would need WOW64 updates.
So I'm betting on two .NET runtimes, 32 and 64 bits, that make no effort to update 32 bit code to 64 bit.
On the other side of the box, the Java JIT compiler should be indeed capable as the Java application itself is platform independent and any features unavailable on a 64 bit CPU would be worked around by the VM, at a small speed cost, on other architectures.
All that sounds good except for one thing...you're wrong. The code is JITed on the fly to be compatible with whatever processor it's running on. IL is processor/machine independent and is agnostic to the differences between 32 and 64 bit platforms. The .Net framework itself takes care of that at runtime.
What do you mean by "64-bit applications cannot access 32-bit libraries, or vice versa" I think you might be misinformed, but I would like to hear you expound a little more into this. Edited 2008-09-26 05:41 UTC
They cannot make direct calls to each other... you can't load a 32-bit dll in a 64-bit program and expect to call into it because there's no good way to switch processor modes when doing that or to provide the correct views of data that's above the 4GB line. There are a couple of other technical reasons why this is impossible.
There is an extensive user-mode thunking layer that allows 32-bit executables to communicate with the kernel, and with RPC servers in other processes, but that's the extent of it.
Just like the push to 32bit from 16bit, during the transition many people thought why do i need to upgrade to 32bit, i don't have anywhere near 4GB RAM, i only have 2MB, 4MB, 8MB etc.
I know aswell as memory there are other architectural reasons to complete the move.
I think it's important that users start the mirgration over to x64 OS's. Drivers will be created, software will be developed, ready for when we do require x64, which personally i think is sooner than alot of people think.
More and more people are watching HD movies on their computers, recording tv shows on MCE computers. The standard is 2GB RAM on PC's, how long before that changes to 4GB RAM and that to 6GB or 8GB RAM?
We need to start getting into the mindset ready for the migration so we don't have a last minute scrabble.
I mean if your next PC came with 4GB or even 8GB RAM wouldn't you want to use it all? I know many people will say they only use their computers for email and surfing, however a lot of people also use their computers for games, video editing, image editing etc, all three OS's Mac OSX, Windows & Linux are all incredibly stable thus allowing for more and more applications to be mutlitasked and ran at the same time, we have more background tasks (music playing etc..).
I hope Microsoft start a push in the consumer space for x64 windows, even if the machines come with 2GB RAM, just prepping everyone for the migration is worthwhile.
Edit : Thought whilst watching the article on MultiTouch.
The other thing i suppose to bear in mind is new technology. So for example if the multitouch system explained in the other OSNews article is ready for release but requires 1GB/2GB of RAM to run then again x64 will become a Necessity. Edited 2008-09-26 08:36 UTC
I usually avoid bashing Windows and comparing to Linux, but come on :
* 32bit libs in "SysWOW64" folder, and 64bit libs in "system32" folder ? Makes perfect sense (sarcasm). Same goes for "program files" folder, even if less troubling (but why do those need to be in different folders at all ?).
* Separate configuration locations for 32bit and 64bit (in registry) ? Who stores bitwidth-sensitive data in there ? And relies on the OS to handle the case when both 32bit and 64bit versions of the program being installed at the same time ?
* Configured data sources (ODBC) only working for n-bits program if configured via n-bits GUI ? I'd really expected better.
Compare this with Linux, where there a "/lib32" and a "/lib64" folder which contain the expected, plus a "/lib" symlink that points to "/lib64". All the rest (configuration , applications, etc) is in the standard (bitwidth-agnostic) locations. I've been using 64bit Linux on my laptop since 2004, and it allways worked just as well as my 32bit machines.
Of course I know why Microsoft does these kind of hacks : backward-compatibility. That's the price paid for proprietary software, which often won't issue any update once the package has been sold. And Microsoft has been blessing this behaviour by working around 3rd-party bugs in each new version of Windows. They've been doing it for at least 15 years, and can't turn back.
Pardon the pun, but the bazaar is much tidyer and well-kept than the cathedral.
In order to mix 32-bit and 64-bit code, you have to make your library an out of process COM server.
Device drivers (including printer drivers) must be 64-bit on x64.
Seriously, do you know any casual user (I mean like my mom), that would bother because their 64bits system files are installed into the system32 directory? All of these excuse are somewhat doubtfull when it come to ordinary people. Except for badly written application, all of the WoW64 layer stuff should be transparent.
What advantage is there to run 64bit? Hum, let me see... RAM!!! Vista loves RAM. It love it so much that it can but rape your hard drive so hard that it will be screaming "Help I can't handle that page file anymore! " I work in a computer store (custom built) and we sell lots of RAM. Our standard family system has 2gigs of RAM and our gamer one begins with 4gigs. We sell 8gigs system more and more often. A lot of people who take Vista get the 64bits edition too, just because they wont have to reinstall their machine when they'll add more than 3.5gigs of RAM.
What I'm recommending, is that if you're running on Vista and not planning on using old or esoteric hardware, get 64bits. The performance difference is minimal, and the memory usage only increase slightly. Most drivers are now stable in both version and theres more and more application that can take advantage of more RAM. Just give it a try. If you don't like it, than reinstall to 32bit, your OEM license do both