寻找有关“正确”的文档在 Windows 7 上安装应用程序的方法

发布于 2024-10-31 14:04:14 字数 369 浏览 6 评论 0原文

我正在使用一些遗留应用程序（10-15 年），并试图找到有关在 Windows 7 上安装和运行它们（以及任何用户应用程序）的“正确”方法的指导，而无需完整的管理员权限。

换句话说，可执行文件/只读文件应该放在哪里，用户数据/读写文件应该放在哪里，注册表项应该放在哪里，以避免在安装和运行期间UAC和Windows 7文件/注册表虚拟化出现问题。运行时。

我似乎记得几年前，微软关于这个主题的白皮书，但现在找不到任何相关信息。我找到了有关用户端的信息（如何通过兼容性调整让旧版应用程序在 Windows 7 上运行），但没有找到有关开发人员端的信息（如何创建/安装应用程序以在 Windows 7 上正常运行）。

任何指向此类信息的指针将不胜感激。谢谢。

马克

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

池予 2024-11-07 14:04:14

您正在考虑Windows 徽标要求< /a>.

默认安装到正确的文件夹
用户应该具有一致且
默认的安全体验
文件的安装位置，同时
保留安装选项
应用到他们所在的位置
选择。还需要保存
应用程序数据正确
允许多人的位置
使用同一台计算机，无需
损坏或覆盖彼此的数据和设置。
Windows 提供
文件系统中的特定位置
存储程序和软件
组件、共享应用程序数据、
和特定于的应用程序数据
用户：
默认情况下，应用程序应安装到 Program Files[16] 文件夹中。由于为此文件夹配置的安全权限，用户数据或应用程序数据绝不能存储在此位置
[16] %ProgramFiles% 分别适用于本机 32 位和 64 位应用程序，以及 %ProgramFiles(x86)% 分别适用于在 x64 上运行的 32 位应用程序
必须在计算机上的用户之间共享的所有应用程序数据都应存储在 ProgramData 中
所有特定用户专有且不得与计算机的其他用户共享的应用程序数据必须存储在 Users\\AppData
切勿直接写入“Windows”目录和/或子目录。使用正确的方法安装文件，例如字体或驱动程序
在“每台计算机”安装中，用户数据必须在首次运行时写入，而不是在安装期间写入。这是因为安装时没有正确的用户位置来存储数据。应用程序在安装后尝试在计算机级别修改默认关联行为将不会成功。相反，必须在每个用户级别声明默认值，这可以防止多个用户覆盖彼此的默认值。

其次，您不应该写入任何需要管理权限的位置。

注意：您只需以标准用户身份运行（根据 Windows 2000 徽标要求）即可在 Windows 2000 或 Windows XP 上测试所有这些内容。

由于大多数应用程序忽略了徽标要求，并且在使用标准用户权限运行时会失败，因此 Windows Vista 提供了通过虚拟化对受保护位置的写入来使这些有缺陷的应用程序保持跛行的功能，而不是让它们失败。

您可以通过将您的应用程序显示为 RunAs Invoker 来选择退出此兼容黑客：

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
    ...
    <!-- Disable file and registry virtualization -->
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
        <security>
            <requestedPrivileges>
                <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
            </requestedPrivileges>
        </security>
    </trustInfo>
    ...
</assembly>

徽标指南讨论了 UAC 和对某些位置写入的虚拟化：

遵循用户帐户控制 (UAC) 准则
一些 Windows 应用程序运行在
管理员的安全上下文
帐户，并且许多需要过多
用户权限和 Windows 特权。
控制对资源的访问
使用户能够控制
他们的系统针对不需要的 20
变化。最重要的规则是
控制对资源的访问是
提供最少的访问量
所需的“标准用户上下文”
用户执行他或她必要的操作
任务。遵循 UAC 指南
为应用程序提供
需要时需要必要的权限，
无需不断离开系统
面临安全风险。
大多数应用程序不需要
运行时的管理员权限，
并且应该可以很好地运行
标准用户。 Windows应用程序
必须有一个清单 21（嵌入或
外部 22 ）定义了它们的
执行级别并告诉操作系统什么
应用程序所需的权限
命令运行。
例如，
应用程序的主进程必须以标准用户身份运行
（作为调用者）。任何行政
功能必须移动到一个单独的
与管理一起运行的进程
特权。
运行其主程序的应用程序需要豁免
具有提升权限的进程 23
（需要管理员或
最高可用）
将考虑豁免
以下场景：
执行级别设置为的管理或系统工具
最高可用，和或
需要管理员
或者
仅限辅助功能或 UI 自动化框架应用程序设置
uiAccess 24 标志设置为 true 以绕过用户界面权限隔离
（UIPI）

然后是高 dpi。十年来的 Windows 徽标要求要求应用程序能够对高（即非 96dpi）显示器做出适当的响应。由于如果用户确实使用“大字体”，大多数应用程序都会严重崩溃，因此微软放弃了，并且像文件系统的虚拟化一样，他们也虚拟化了 dpi 设置。除非应用程序选择退出兼容性破解：Windows 会欺骗您并告诉您您的分辨率是 96dpi。

只有正确编写应用程序后，才应在应用程序清单中添加一个条目以禁用高 dpi 缩放：

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
    ...
    <!-- We are high-dpi aware on Windows Vista -->
    <asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
        <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
            <dpiAware>true</dpiAware>
        </asmv3:windowsSettings>
    </asmv3:application>
    ...
</assembly>

无论如何，一切都在那里，Windows 7 客户端软件徽标计划。

注意：如果您在 15 年前（1995 年）编写 Windows 应用程序，我假设您正在为以下操作系统编写：

Windows 3.1 或
Windows 95，

而不是：

Windows NT 3.1
Windows NT 3.5
Windows NT 4
Windows 2000
Windows XP

值得注意的是，Windows NT 被设计为一个安全操作系统。你不可以随意做任何你想做的事。有着根本的区别

Windows 1
Windows 2
Windows 3
Windows 3.1
Windows 95
Windows 98
Windows Me

这与没有安全性的

。写入 Windows 和 Program Files 文件夹需要管理员权限。这是因为通常只有管理员才应该安装应用程序。但普通用户无法修改或损坏已安装的程序 - 或 Windows 本身的安装，例如：

You're thinking of the Windows Logo Requirements.

Install to the correct folders by default
Users should have a consistent and
secure experience with the default
installation location of files, while
maintaining the option to install an
application to the location they
choose. It is also necessary to store
application data in the correct
location to allow several people to
use the same computer without
corrupting or overwriting each other's data and settings.
Windows provides
specific locations in the file system
to store programs and software
components, shared application data,
and application data specific to a
user:
Applications should be installed to the Program Files[16] folder by default. User data or application data must never be stored in this location because of the security permissions configured for this folder
[16] %ProgramFiles% for native 32-bit and 64-bit applications, and %ProgramFiles(x86)% for 32-bit applications running on x64 respectively
All application data that must be shared among users on the computer should be stored within ProgramData
All application data exclusive to a specific user and not to be shared with other users of the computer must be stored in Users\\AppData
Never write directly to the "Windows" directory and or subdirectories. Use the correct methods for installing files, such as fonts or drivers
In “per-machine” installations, user data must be written at first run and not during the installation. This is because there is no correct user location to store data at time of installation. Attempts by an application to modify default association behaviors at a machine level after installation will be unsuccessful. Instead, defaults must be claimed on a per-user level, which prevents multiple users from overwriting each other's defaults.

Next is that fact that you should not be writing to any location that requires administrative permissions.

Note: You can test all of this on a Windows 2000 or Windows XP simply by (as Windows 2000 Logo Requirements required) running as a standard user.

Since most applications ignored the logo requirements, and would fail when run with standard user privileges, Windows Vista included the ability to keep these buggy applications limping along by virtualizing writes to protected locations - rather than having them fail.

You can opt out of this compatibly hack by manifesting your application to RunAs Invoker:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
    ...
    <!-- Disable file and registry virtualization -->
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
        <security>
            <requestedPrivileges>
                <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
            </requestedPrivileges>
        </security>
    </trustInfo>
    ...
</assembly>

The logo guidelines talk about UAC and virtualization of writes to certain locations:

Follow User Account Control (UAC) Guidelines
Some Windows applications run in the
security context of an administrator
account, and many require excessive
user rights and Windows privileges.
Controlling access to resources
enables users to be in control of
their systems against unwanted 20
changes. The most important rule for
controlling access to resources is to
provide the least amount of access
“standard user context” required for a
user to perform his or her necessary
tasks. Following UAC guidelines
provides applications with the
necessary permissions when needed,
without leaving the system constantly
exposed to security risks.
Most applications do not require
administrator privileges at run time,
and should be just fine running as a
standard-user. Windows applications
must have a manifest 21 (embedded or
external 22 ) that defines their
execution levels and tells the OS what
privileges the application requires in
order to run.
For example,
The main process of the application must be run as a standard user
(asInvoker). Any administrative
features must be moved into a separate
process that runs with administrative
privileges.
A waiver is required for applications that run their main
process 23 with elevated privileges
(requireAdministrator or
highestAvailable)
Waivers will be considered for the
following scenarios:
Administrative or system tools with execution level set to
highestAvailable, and or
requireAdministrator
Or
Only Accessibility or UI automation framework application setting the
uiAccess 24 flag to true to bypass the user interface privilege isolation
(UIPI)

Then there was high-dpi. The Windows Logo requirements for a decade has required applications to respond appropriately to high (i.e. non-96dpi) displays. Since most applications break horribly if the user does use "Large Fonts", Microsoft gave up and, like virtualization of the file system, they also virtualize the dpi setting. Unless an application opts out of the compatibility hack: Windows will lie to you and tell you that you are 96dpi.

Only once you've written your app properly should you add an entry to your application's manifest to disable high-dpi scaling:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
    ...
    <!-- We are high-dpi aware on Windows Vista -->
    <asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
        <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
            <dpiAware>true</dpiAware>
        </asmv3:windowsSettings>
    </asmv3:application>
    ...
</assembly>

Anyway, it's all there, the Windows 7 Client Software Logo Program.

Note: If you were writing a Windows application 15 years ago (1995) i assume you were writing for:

Windows 3.1, or
Windows 95

rather than:

Windows NT 3.1
Windows NT 3.5
Windows NT 4
Windows 2000
Windows XP

It's important to note that Windows NT was designed as a secure operating system. You are not allowed to arbitrarily do anything you want. This is a fundamental difference from:

Windows 1
Windows 2
Windows 3
Windows 3.1
Windows 95
Windows 98
Windows Me

which had no security.

Writes to the Windows and Program Files folder requires administrator permission. This is because normally only administrators should install applications. But it regular users cannot modify, or damage, installed programs - or the installation of Windows itself, e.g.:

回复收藏 0 原文