Windows-itpro-docs: About the 64-Bit Incompatibility

[Amaroq-Clearwater]

Why are 64-Bit processes unsupported in Virtualization and in Installer Detection? I'd be interested in hearing the technical reasons for it, and whether or not this could be implemented in the future.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 495688e2-ca8d-a005-19d2-5ee9138c86f2
• Version Independent ID: 760f236c-5eb0-00cd-9553-990f29ee5aa4
• Content: How User Account Control works (Windows 10)
• Content Source: windows/security/identity-protection/user-account-control/how-user-account-control-works.md
• Product: w10
• GitHub Login: @brianlic-msft
• Microsoft Alias: justinha

[HumanEquivalentUnit]

It is not technically incompatible, it's a design decision. Virtualization was made as a compatibility feature so that when badly written programs which assumed they had administrator access were run in Windows Vista, they could still work instead of crash.

Newer software doesn't need this feature; if developers try to build new software in the same way, it won't work right from the start. They now have no choice but to build 64bit software "properly" in the first place, so it will never need virtualization.

Important: Virtualization is implemented to improve application compatibility problems for applications running as a standard user on Windows Vista. Developers must not rely on virtualization being present in subsequent versions of Windows.

Prior to Windows Vista, many applications were typically run by administrators. As a result, applications could freely read and write system files and registry keys. If these applications were run by a standard user, they would fail due to insufficient access. Windows Vista improves application compatibility for these users by redirecting writes (and subsequent file or registry operations) to a per-user location within the user's profile.

and

Virtualization is intended only to assist in application compatibility with existing programs. Applications designed for Windows Vista should NOT perform writes to sensitive system areas, nor should they rely on virtualization to provide redress for incorrect application behavior. When updating existing code to run on Windows Vista, developers should ensure that, during run-time, applications only store data in per-user locations or in computer locations within %alluserprofile% (CSIDL_COMMON_APPDATA) that have access control list (ACL) settings properly set.

Important Microsoft intends to remove virtualization from future versions of the Windows operating system as more applications are migrated to Windows Vista. For example, virtualization is disabled on 64-bit applications.

from https://msdn.microsoft.com/en-us/library/bb530410.aspx

that is, the only reason to implement it in future is to allow people to be able to write programs that work badly.

[Amaroq-Clearwater]

Ah. Things are starting to make more sense to me... but even enabling Installer Detection for 64-bit installers?

[HumanEquivalentUnit]

The installer detection is for the same reason - installers saving things outside the user folder / registry paths and into the system locations, without being UAC aware, would fail when that access was denied. Windows Vista detects the installer and prompts for UAC elevation first so they do have admin rights, and will work - it's a workaround for badly coded software that was created for a world before UAC existed.

Installers developed since Windows Vista came out 12 years ago, ought to be aware of this design, and either install inside user folders/registry paths only, or request UAC elevation themselves.

I don't know why 64-bit was chosen as a cutoff, because there was a 64-bit Windows XP from 2005, but there ought to be little reason to do installer detection - only for programs with 64-bit installers, developed pre-Vista, with no updates to make them work properly in the last decade. And if you have one of those programs, chances are you know about it by now and can easily run it with elevation yourself, e.g. using start-process -verb runas, and don't need a billion computers to get a whole new compatibility layer to help you do that.

[mypil]

@Amaroq-Clearwater - Thank you for submitting this feedback.

From our understanding, your query has been answered already. If you feel it hasn't been resolved please re-open this issue.

[mypil]

@AndreaBarr - This issue can be closed. Thank you.