There are many users that already have a computer with processor that supports the x64 architecture and some of them probably consider to move into the new world of 64-bit and install the x64 version of Windows.
if you’re one of these users, you should read the following tips before doing any step:
- First, let’s start with the good part: The x64 version of Windows have an emulation known as “WOW64” which allows you to install, run and use almost every existing 32-bit application that you currently use in your 32-bit version of Windows. I said the word ‘almost’ because there are some exceptions that will be explained in the next clauses.
- Device Drivers: As opposed to applications, 32-bit drivers cannot be used under x64 version of Windows. This means that must have the appropriate 64-bit driver for every hardware product that you want to use. For standard hardware products like simple mouse and keyboard, you don’t have to worry, because Windows x64 already packed with the right drivers. But if you use some uncommon hardware devices, you should check if the manufacturer of these devices provide x64 drivers for these devices.
- There are some applications that load and use one or more drivers that are needed for their functionality. Just for example: Process Explorer and some other tools of SysInternals load their own driver that is used to extract information from Windows Kernel.
These kind of tools won’t work under x64 system, unless the software developer provide the software with the appropriate 64-bit driver. In the case of SysInternals tools, there is no problem, because these tools are shipped with both 32-bit and x64 drivers, and the right driver is loaded according to the version of Windows.
However, there are some software developers that only provide a driver for 32-bit, and thus their software won’t work under x64. - Starting from x64 version of Windows Vista, Microsoft added a security feature that many people don’t know about: Every driver that is loaded into Windows Kernel must be digitally signed. Signing a driver can only be done by a commercial entity and requires also to pay hundred of $ per year for the Commercial Software Publisher Certificate.
Microsoft added this feature in order to prevent from malware/Viruses/Trojans creators from loading and running malicious code inside the Windows kernel. Unfortunately, they also blocked many legitimate small developers from porting their driver based application into 64-bit.
One example is my own OpenedFilesView utility. This utility uses a small device driver for extracting information about the opened file handles stored in the Windows kernel. (There is no any other way to get this information)
Due to above Kernel changes in Vista x64, I cannot port this utility into Windows x64. I already had some users that moved from 32-bit to x64 system and disappointed after they found out that they would not be able to use my OpenedFilesView utility in their new x64 system.
In theory, I can open a real company with office, phone, and address, purchase a Commercial Software Publisher Certificate, do the entire process of signing my driver, and then sell the x64 version of OpenedFilesView for $10-$15. However, I don’t think that the sells of this software will cover the costs of maintaining a company and Certificate payments. - There are some applications that inject a dll file into other programs (Windows Hooks) in order to interact with their user interface or to grab some information from them. For example, My Volumouse utility change the mouse wheel behavior when the focus is on other applications, and thus it inject a special dll for every application that interact with the mouse wheel.
When you run this kind of application on x64 system, it’ll probably work well with other 32-bit application, but it won’t be able to interact with other x64 applications, unless the software developer added a support for x64 systems. - Windows Registry on x64 version of Windows is a little confusing: Some of the Registry keys are common for both 32-bit and x64 applications, while some Registry keys have 2 separated instances – one for 32-bit applications and one of 64-bit applications. The separated keys for 32-bit applications are stored under HKEY_LOCAL_MACHINE\Software\Wow6432Node and HKEY_CURRENT_USER\Software\Wow6432Node.
- On x64 system, every memory address, file handle, window handle, and other kernel objects, consume 8 bytes in memory (64-bit = 8 bytes), while on 32-bit systems, only 4 bytes are used. This means doing the same work on x64 might consume much more memory than on 32-bit system, even when in many cases, the usage of 8 bytes is not really necessary.
- Many applications vendors still don’t provide a separated 64-bit version of their application, and instruct their x64 users to use their 32-bit application. Even if the 32-bit application works perfectly on x64 system, it’s still running on WOW64 emulation, and this means that the application might be a little slower than on a real 32-bit system.
However, if the application vendor provide a separated version for x64, running the x64 version of x64 system might give you better performances than using the 32-bit application on 32-bit system.
Dapxin says:
pt.8 was one very useful bit I ‘d never thought of… thx!
September 22, 2009, 5:11 amMikael says:
For #4.
Run in CMD as admin
bcdedit.exe -set loadoptions DDISABLE_INTEGRITY_CHECKS
bcdedit.exe -set TESTSIGNING ON
reboot
OpenedFilesView should work now
Since im in XP i cant verify this but im pretty sure it should.
September 22, 2009, 9:05 amMikael says:
And to Nir:
September 22, 2009, 9:20 amI mail an pdf with instructions how to sign your own drivers.
Hope this will work for you.
ender says:
I remember reading somewhere that 32bit applications were actually 2-3% faster when running in x64 Windows compared to running in 32bit Windows on the same hardware.
October 5, 2009, 3:10 pmrey says:
I very appreciate your OpenedFilesView and hate MS for the issue 4. Never mind, I suggest you to create your unsigned OpenedFilesView driver for W7x64 and let users to solve the problem of loading the driver. Thanks god there are some known tricks for this.
October 7, 2009, 2:28 pmyer says:
rey , what are these known tricks ? Any links for us ?
October 21, 2009, 6:24 amHaudy Kazemi says:
Here are two posts on how to use unsigned drivers with Vista x64…
http://forums.laptopvideo2go.com/topic/18585-installing-unsigned-drivers-in-vista-x64/
http://forum.xcpus.com/operating-systems/5767-howto-use-unsigned-drivers-under-vista-x64.html
The workaround is for the user to use another tool to solve the signing problems. Some such tools include ReadyDriverPlus and Driver Signature Enforcement Overrider.
November 2, 2009, 8:51 pmpcunite says:
Quote from #7 ” x64 might consume much more memory than on 32-bit system”
This has yet to realize itself in any meaningful way. x64 has proven itself to benefit users and you can’t have something in this world without cause and effect. It would be best to not sweat the little things. As a programmer your used to dealing with the details but you will drive yourself crazy from caring about this point. Just let it go and don’t confuse customers by telling them pointer sizes cause bloat.
November 7, 2009, 9:03 amRatz says:
@pcunite,
Not all pc users are morons, some are actually intelligent users that unfortunately aren’t intimate programmers either. I for one am grateful for this list and found the fact that if obviously (if you think about it and know the difference of 4-bytes vs. 8-bytes) causes bloat.
Unfortunately, I don’t understand why the system has to always use all 64-bits and rather has a method of calling the appropriate 16/32/64-bit registers instead.
I will give you an example where this does realize itself, at our University, in the engineering labs, the available RAM and CPU upgrades for hundreds of PC’s is limited, certain machines need higher spec for CAD graphics handling too. Budgets on PC’s are thus limited, especially as other high end technical equipment must also be purchased.
Now, you sit with a bloat filled OS, running bloat filled applications and bloat filled security measures. Each little variable in those programs don’t all require that 64-bits, but they get it. (yes, appropriate variable type assigning aside), but all this bloat decreases the efficiency of the machine, on top of this you now have students coding, running simulations etc all bogged down because of the bloat.
Users should get out of this rubbish of “oh I am confused.” and learn a bit about the workings of the things they are using. Given the nature of the rest of this useful website, I really doubt the target audience was the average consumer home user or secretary/businessman who has Vista 64 for typing, emails, facebook and pr0n.
@Nir,
Thanks for the list, is an interesting read and decent explanation.
November 21, 2009, 1:43 pmWytnoiZ says:
Yikes, I hit this thread at the wrong time (or perhaps the right). I’ve spent the last week making images/backing up, getting prog updates, drivers, etc. I was finally ready to perform my Win7 install TODAY. Reading the above informed me about concerns I hadn’t considered (uh, many more such concerns have presented themselves during the last week too)…My first foray into x64 has been more intense than building a machine from scratch!
That settles it…definitely going to *dual boot* Vistax32 & Win7x64 Home Premium for awhile. Thanks to all, and MANY thanks to Mr. Sofer for some incredibly useful utils!
November 25, 2009, 11:55 amthe_elektronik says:
First of all I’m very happy with Vista x64 SP1.
64-bit OS supports more RAM than 32-bit systems [4GB RAM cap]
32-bit hardware intensive software benefit somehow with up to 8% efficiency increase on the same hardware.
I’m using it now for about 2 years and it has never BSOD’ed me yet.
Vista x64 is a fairly acceptable OS but it is not all that good. There are many annoyances and some of them are:
– minor 32-bit software compatibility issues
– User Account Control [UAC] is very annoying but easy to turn off
– Vista has a complete mess with its system folders
– Driver Signature Enforcement preventing installation of third party drivers
– Vista blocks access to user files and system sub-folders, obtaining OWNERSHIP is required for access
– installing DX11 requires upgrade to SP2 [577MB] or [745MB] for multi-language support
– more complex system registry
– Windows side-by-side [WinSxS] occupies a lot of space on the HDD often 5GB for average user and over 10GB if additional software or multiple versions of the same software are installed
– File indexing, it is really trashing HDDs especially if you have about 5TB in HDDs with about 1kk files on them and about 100k in windows folder alone
– OS goes over 260 character long path length by itself in USERS and DOCUMENTS AND SETTINGS directories. well, NTFS supports over 32k path length but Windows API allows 260 characters only. I noticed that explorer switches to \XXXXXX~1\ directory name and I reached 28 dirs deep totaling over 480 character long path before explorer gave me an error. the CPU utilization was very high and changing a directory required few seconds.
– problems with soundcards noticeably line-in/mic pass through and audio out recording.
[on some hardware configurations it can be fixed with registry/driver hacks but often extremely difficult to fix]
[problems with playback and recording an audio from capture cards, TV/sat cards and video grabbers]
As for now I have a Dual Boot, Vista x64 and XP x86. I had to connect a Sound Blaster USB for two reasons. XP doesn’t support my HDAudio soundcard and Vista can’t record digitally from it but can record via digital-analog converters loosing quality.
I have multiple Virtual machines installed as well for testing purposes.
MOST OF IT IS AN VISTA THING
January 1, 2010, 10:08 pmInstall XP x64 for all benefits regarding 64-bit hardware support, well almost [DX9].
Tyra Misoux says:
I moved to Win7/64 and Ubuntu/64. The real 8 GB memory is a dream when working with lot of huge pictures for example while having a virtualbox runnig as well as the browser.
January 16, 2010, 5:07 amI am not sure yet if disabling that driver integrity check is a good idea.
There are some cool Microsoft tools (by Marc Russinovich, http://technet.microsoft.com/en-us/sysinternals/default.aspx) also providing a tool (handle) to list (and force close) open files. This works for 64 bit.
Btw. Nir, you should add a “paypal”-Button to your site.
London Bloke says:
Hello, First of all, what a interesting article! i am just researching for my blog but i had a problem reading this post because the text sticking out in to the side menu…. edit… oops! the problems my end, its my ancient version of opera causing the bug. Might be worth asking peeps to update. All the best. London Bloke
October 4, 2010, 12:23 pm