I love this tablet except I didn't realize it is running 32-bit win8.1 which sucks. Anyone know if there is a way I can get Win 8.1 64-bit on it?
Dell Venue Pro 11 (Bay Trail) Can it run Win8.1 64bit?
- Thread starter redfusion87
- Start date
Maybe he needs features that are supported on 64 bit systems.
OP, technically speaking, intel atom supports 64 bit architecture, however, since you only have 2 GB of RAM, performance will be severely crippled.
There is no point in using a 64 bit system with less than 4 GB of RAM.
That's not entirely true. First of all, "severely crippled" is quite an overstatement; you'll lose a few percent CPU efficiency while executing 32-bit programs, and cache coherency will suffer a bit, but the impact is barely noticeable and has nothing to do with RAM size (that is, you'll take the same hit for running 32-bit code on a 64-bit OS whether you have 2GB or 20GB). Program binaries (64-bit ones, that is) are usually larger, which consumes both more storage and more RAM once they're loaded, but they also get to use the extra registers and instructions (including native 64-bit integer math) that are available to 64-bit-aware programs, which can actually make them more efficient than their 32-bit counterparts in some cases. In other cases, they will be very slightly slower (largely due to cache coherency loss from the large pointer values) but the difference is pretty small.
Then, there's security. 64-bit programs can use high-entropy ASLR, which makes ASLR *vastly* more effective (32-bit OSes typically use only 8 or 12 bits of entropy for ASLR, which is good but still permits brute-forcing on repeatable attacks, and the occasional lucky hit in any case; HE-ASLR uses enough entropy that you could exploit every PC on the planet and still have a fair chance of missing every time). 32-bit programs have such small heaps that a heap-spraying attack (writing a NOP-sled into the payload instructions, so that if you pivot the instruction pointer onto the heap you will "slide down" to the payload) is practical, typically taking less than a second; on a 64-bit process, even if you could commit enough virtual memory (you can't; no existing PC can) it would take *years* to spray it all.
Finally, a nitpick about setting the threshold at 4GB for where 64-bit is needed instead of 32-bit. Video memory is typically mapped into the kernel address space, as are the I/O buffers for other drivers. In the old days, this was no big deal; a PC could easily afford to give up even a gig or so of kernel address space (assuming you weren't trying to assign more than 2GB to user-mode per-process allocation) and as long as you didn't have more than 3GB of physical memory, the memory manager could still address the rest of it. These days, even cheapo GPUs sometimes have more memory than that, and even a merely decent graphics card will have so much VRAM that a 32-bit system couldn't address all of it using the default 2GB user / 2GB kernel split. This isn't really a problem for embedded graphics, but anybody using 32-bit with a modern discrete GPU is nuts.
Then, there's security. 64-bit programs can use high-entropy ASLR, which makes ASLR *vastly* more effective (32-bit OSes typically use only 8 or 12 bits of entropy for ASLR, which is good but still permits brute-forcing on repeatable attacks, and the occasional lucky hit in any case; HE-ASLR uses enough entropy that you could exploit every PC on the planet and still have a fair chance of missing every time). 32-bit programs have such small heaps that a heap-spraying attack (writing a NOP-sled into the payload instructions, so that if you pivot the instruction pointer onto the heap you will "slide down" to the payload) is practical, typically taking less than a second; on a 64-bit process, even if you could commit enough virtual memory (you can't; no existing PC can) it would take *years* to spray it all.
Finally, a nitpick about setting the threshold at 4GB for where 64-bit is needed instead of 32-bit. Video memory is typically mapped into the kernel address space, as are the I/O buffers for other drivers. In the old days, this was no big deal; a PC could easily afford to give up even a gig or so of kernel address space (assuming you weren't trying to assign more than 2GB to user-mode per-process allocation) and as long as you didn't have more than 3GB of physical memory, the memory manager could still address the rest of it. These days, even cheapo GPUs sometimes have more memory than that, and even a merely decent graphics card will have so much VRAM that a 32-bit system couldn't address all of it using the default 2GB user / 2GB kernel split. This isn't really a problem for embedded graphics, but anybody using 32-bit with a modern discrete GPU is nuts.
Yes, however DELL has not released any 64-bit drivers for the touchscreen or any other component. You would need to install this with the device connected to a powered USB hub connected to a keyboard and mouse with a optical drive/flash drive with a bootable installation. Remember the touchscreen will not work during the installation process. Migrating to 64-bit on THIS particular tablet isn't worth the stress that you seek in my opinion. I went this route by turning off secure boot in the BIOS, but after doing a clean install, I found it wasn't worth it other than being able to use the "full" 32GB without the recovery partition and other junk. You will have to do a Windows update to get the generic drivers. Windows will load the integrated graphics and the WiFi natively, but it still isn't worth the hassle. Luckily, I had created a recovery flash drive and restored from that.
Going 64 bits on less than 4 GB of RAM is like asking to get yourself the slowest possible computer.
You won't be able to do any sort of real multitasking, since the system itself will use twice the amount of RAM it uses on 32 bit systems.
A typical 64 bit windows uses around 1 GB of RAM. Witch means that out of the 2 GB the OP has, only 1 will be usable. A browser nowadays uses around 300MB, even more depending on tabs. The moment RAM consumption reaches a certain level, windows will start moving contents to the hard disk, making the entire computer much slower.
So yes, his performance will be severely crippled. I run a 64 bit OS on 2 GB ram once. It was horrible. I won't ever do it again.
And I doubt the OP needs better ecnyption keys on his tablet.
Let's not even dive into driver problems and other stuff which comes along. Dell is obviously only supporting the 32 bit OS. Otherwise they would have tossed 4 gigs of RAM and the 64 bit OS and increase the price by like 30 bucks and be done with it.
Windows (by default) has generic drivers
my Asus T100 Bay Trail with a clean Windows 8.1 x86 ISO could boot to desktop, but missing sound, wifi and other stuff
why don't you try it? Use the Windows 7 DVD ISO tool to create a bootable USB and try
http://www.microsoftstore.com/store/msusa/html/pbPage.Help_Win7_usbdvd_dwnTool
my Asus T100 Bay Trail with a clean Windows 8.1 x86 ISO could boot to desktop, but missing sound, wifi and other stuff
why don't you try it? Use the Windows 7 DVD ISO tool to create a bootable USB and try
http://www.microsoftstore.com/store/msusa/html/pbPage.Help_Win7_usbdvd_dwnTool
With all due respect, claiming that a 64-bit system uses 2x the RAM is absurd. The kernel uses 64-bit pointers internally on either 32-bit or 64-bit systems (to support PAE, which is enabled for NX/DEP support even though the addressable range is still capped to 4GB on client SKUs). Non-pointer data structures are not defined in terms of "int" and "long", but in terms of DWORD (which is always 32 bits, whether on the 16-bit systems that the type got its name from, or on 32-bit or 64-bit machines), LARGE_INTEGER, etc. A fresh Win8 x64 install, at the desktop, uses about 280MB of RAM.
I have personally used both 32-bit and 64-bit OSes on the same 2GB-of-RAM hardware, and I assure you: the difference in performance is not perceptible except benchmarks. This was a Vista system, to boot; Vista uses more RAM than Win7, much less Win8.
I have personally used both 32-bit and 64-bit OSes on the same 2GB-of-RAM hardware, and I assure you: the difference in performance is not perceptible except benchmarks. This was a Vista system, to boot; Vista uses more RAM than Win7, much less Win8.
I use a 5-year old desktop with a Intel Core2Duo processor and 2 GB of RAM, and it happily runs 64-bit Windows 8.
Yes, I do a lot of multitasking and have 10-12 tabs open in my browser at any given time, and I don't see any noticeable difference from when the same system used to run 32-bit Windows.
Rufus is better for creating bootable USB IMO:
Found the MS tool a bit flaky, often refuses to write to drives.
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
2That's not entirely true. First of all, "severely crippled" is quite an overstatement; you'll lose a few percent CPU efficiency while executing 32-bit programs, and cache coherency will suffer a bit, but the impact is barely noticeable and has nothing to do with RAM size (that is, you'll take the same hit for running 32-bit code on a 64-bit OS whether you have 2GB or 20GB). Program binaries (64-bit ones, that is) are usually larger, which consumes both more storage and more RAM once they're loaded, but they also get to use the extra registers and instructions (including native 64-bit integer math) that are available to 64-bit-aware programs, which can actually make them more efficient than their 32-bit counterparts in some cases. In other cases, they will be very slightly slower (largely due to cache coherency loss from the large pointer values) but the difference is pretty small.
Then, there's security. 64-bit programs can use high-entropy ASLR, which makes ASLR *vastly* more effective (32-bit OSes typically use only 8 or 12 bits of entropy for ASLR, which is good but still permits brute-forcing on repeatable attacks, and the occasional lucky hit in any case; HE-ASLR uses enough entropy that you could exploit every PC on the planet and still have a fair chance of missing every time). 32-bit programs have such small heaps that a heap-spraying attack (writing a NOP-sled into the payload instructions, so that if you pivot the instruction pointer onto the heap you will "slide down" to the payload) is practical, typically taking less than a second; on a 64-bit process, even if you could commit enough virtual memory (you can't; no existing PC can) it would take *years* to spray it all.
Finally, a nitpick about setting the threshold at 4GB for where 64-bit is needed instead of 32-bit. Video memory is typically mapped into the kernel address space, as are the I/O buffers for other drivers. In the old days, this was no big deal; a PC could easily afford to give up even a gig or so of kernel address space (assuming you weren't trying to assign more than 2GB to user-mode per-process allocation) and as long as you didn't have more than 3GB of physical memory, the memory manager could still address the rest of it. These days, even cheapo GPUs sometimes have more memory than that, and even a merely decent graphics card will have so much VRAM that a 32-bit system couldn't address all of it using the default 2GB user / 2GB kernel split. This isn't really a problem for embedded graphics, but anybody using 32-bit with a modern discrete GPU is nuts.1With all due respect, claiming that a 64-bit system uses 2x the RAM is absurd. The kernel uses 64-bit pointers internally on either 32-bit or 64-bit systems (to support PAE, which is enabled for NX/DEP support even though the addressable range is still capped to 4GB on client SKUs). Non-pointer data structures are not defined in terms of "int" and "long", but in terms of DWORD (which is always 32 bits, whether on the 16-bit systems that the type got its name from, or on 32-bit or 64-bit machines), LARGE_INTEGER, etc. A fresh Win8 x64 install, at the desktop, uses about 280MB of RAM.
I have personally used both 32-bit and 64-bit OSes on the same 2GB-of-RAM hardware, and I assure you: the difference in performance is not perceptible except benchmarks. This was a Vista system, to boot; Vista uses more RAM than Win7, much less Win8.
