这个问题并不是良好叙述的。

你应该问自己：“我假设 Y 和 X 之间应该有什么样的关系？”
问完了自然就知道下一步怎么做。

@lujiajing1126 #87 docs.microsoft.com 和 MSDN/TechNet Forums 都是社区的对应物。而且我已经说到了 Windows PowerShell 有更好的“可发现性”。

我觉得“适用于”和“可发现性”听起来太像机器翻译了。对于我来说，评价他人的语言之前先把自己的语言搞对会比较有底气，譬如正确的拼写。

虽然我既不用 macOS 也不用 Keyboard Maestro，你也没贴任何代码，但我的意念告诉我：循环的原因是你不断尝试改变剪贴板。

方法：先查看剪贴板决定是否需要过滤，如果无需过滤就跳过，避免递归触发。

@jasonyang9 #51 根据我最近的了解…搜狐也是要用 Windows Server 的，几乎所有有一定规模的企业都会有一套类似 Windows domain 的机制。

@lujiajing1126 #79 这并不 apply to 你不知道那个命令的情况，而且 Windows PowerShell 对命令的 discoverability 也要比疯狂缩写好很多。

@akring #82 见本楼我的第一个回复，搜狐不是国企。我目前明确知道（因为见到了）的其他用 Windows Server 的企业还有 PwC、Microsoft。

你如何知道这是 Windows 的 bug 而不是别的软件的……？我也遇到了这个问题好几次，但是我一直没有尝试看谁在泄露 handle。

对于 Java 来说，对象的身份是不会变化的，也就是调用 superclass 的构造器的时候，this 就已经是 the most derived class object 了。

调用构造器的时候，已经产生了对象了。

@whileFalse #1 但是我上次用 Windows Server 的时候还不支持 Microsoft account 登录，所以我一直没用。

@o0 #14 存在没有 Desktop Experience 的 Windows Server。

@afc #21 我从来没学会过怎么用 scp。相反，Windows Server 无论是 Remote Desktop，还是 PowerShell cross-session copy，还是直接用默认的 share folder 都很方便。我无法想象 scp 怎么可能比同样正确配置的 share folder （还是默认的）方便。

@Halry #23 3389 和 22 并不是对应的关系，PowerShell Remoting 才是和 SSH 对应的。

@falcon05 #27 Windows Server 的一切内置功能都是可以命令解决的，因为存在没有 Desktop Experience 的版本。

查看你的 locale 和控制太编码是否意外改变。

重新排版功能是一个永远做不好的功能。

@mason961125 #4 楼主介意的是 enroll MDM，而不是 Gmail 客户端的功能问题。

回到题主的问题，答案是：不可能。否则这是一个安全问题。

我觉得 Astro 可能使用了 Google 的 API ？此外 G Suite 还可以用 Exchange ActiveSync 同步，但是 compliant 的 EAS 客户端必须 enforce MDM policy.

所以，用网页版，或者让公司配一个手机，或者下班时间不检查邮件。

@RainyH2O #24 多用户。HKLM 只有管理员等高权限者才可写入。HKCU 是 HKEY_USERS 对应当前用户的 subkey 的映射。

您这个问题很奇怪，因为所有现代的操作系统都有一种区分当前用户的资产和当前机器的资产的功能，注册表里的 key 相当于文件系统的 folder，在一个 hierarchical 的数据存储中无祖先后代关系的节点表示这种区别理解上就很自然，而且还可以利用 ACL 继承的便利。

我的 blog 就是 PowerShell，不过也有外部命令。

@RainyH2O #22 当然不是。

Designed for Windows 的软件需要在 Uninstall a program 里面出现。如果给全部用户安装，你需要把信息写进 HKLM，如果给当前用户安装，你需要写进 HKCU。有些软件会注册 COM 对象 /接口，安装到哪里决定了是写到 HKLM\SOFTWARE\Classes 还是 HKCU\Software\Classes。

安装后修改这个设置最常见、通用和简单的方法是卸载再重新安装。

此外 #21 已经提到，能用 API 就不要用环境变量。最后，那些位置一般是默认安装位置，很多软件可以修改安装位置的。

@ryh #3 @roshad #4

你们提到的是 WinRT API，这是完全不同的模型。WinRT roaming app data 是存在于 Isolated Storage 里面的 RoamingState 和 Settings 里面的，每个 app 的 isolated storage 在目前的情况下默认位置是 %LOCALAPPDATA%\Packages\<Package Family Name> 下。

@ggsimidar #5 他们说的和 %APPDATA% 漫游无关。

@sobigfish #8 我个人的看法是不会。

Roaming user profile 是 Windows domain 的功能，工作原理就是登录的时候从服务器 copy user profile 里面可以 roam 的部分（ user profile 通常是 %USERPROFILE%，但是并不是每个内容都可以 roam ），注销的时候把可以 roam 的部分复制到 domain controller。这在很慢的网络环境下是不可能的（例如离开了通过 Ethernet 连入公司网络的情况），此外，应该避免用户同时登录 forest 里面的多台电脑。

我曾经在 Microsoft 有账户，但我没有观察这些数据是否 roam 过。这个功能的使用频率在逐渐降低。更多阅读材料请见

https://blogs.msdn.microsoft.com/oldnewthing/20050630-20/?p=35143/

@szzhiyang 回到楼主的问题，如果你不是为了企业开发软件，你的 app data 基本上不可能 roam。从逻辑上来说，你应该如此选择存放的位置：%APPDATA% 存和机器无关的数据，且不能太大。%LOCALAPPDATA% 存和机器有关的数据、从云同步的数据、大的数据以及任何删除都没有实际损失的数据。

举个例子，Outlook 把用户的 mail signature 存在 %APPDATA%\Microsoft\Signatures 里，但是用户邮箱的缓存数据存在 %LOCALAPPDATA%\Microsoft\Outlook 里面。前者是因为 mail signature 没有一个统一的云服务，如果用户刚好在启用了 roaming profiles 的 domain 里，则用户可以享受在公司里换电脑之后不需要重新设置签名档的好处。后者是因为，首先邮箱数据的缓存可能很大，其次，邮箱的缓存是一个删除了也没有损失的内容（可以重新从服务器下载），最后，邮箱缓存是从邮件服务器（例如 Exchange Server ）来的，逻辑上就不需要用 roaming profile 同步。

最后：不要用 APPDATA 和 LOCALAPPDATA 去访问这两个文件夹。使用 SHGetKnownFolderPath （.NET 的 System.Environment.GetFolderPath ）。

@Vhc #10

%AppData% = 用户的漫游数据
%UserProfile% = 用户配置文件夹，现在通常是 C:\Users\用户名，默认情况下用户的 known folders 是这个文件夹的子文件夹，但是用户可以修改
%AllUsersProfile% = 所有用户的配置文件夹，注意这不是公用文件夹，修改需要管理员权限，但是创建新文件和修改自己创建的文件不需要（每个用户自动有自己创建的文件夹、文件的全部控制权）
%ProgramFiles% = 整机软件应该默认被安装到的位置，如果你运行在 WoW 64 上，则自动变成 (x86) 版本，如果你是 x64/x86 系统的 x64/x86 进程，则通常是 C:\Program Files
%SystemRoot% = 系统的目录，通常是 C:\Windows
%SystemDrive% = 系统所在的驱动器字母，通常是 C:
%Temp% = %Tmp% = 当前会话（注销之前）的临时文件夹，注意，同一个用户多次登录系统，每次可能有不同的临时文件夹（该情况多见于 Windows Server ）

我觉得这几个东西就没有什么相像的地方。为什么 TEMP 和 TMP 都有呢？兼容性。https://blogs.msdn.microsoft.com/oldnewthing/20150417-00/?p=44213/

此外，能使用 API 就不要用环境变量。因为使用环境变量有可能被启动你的进程骗（这可以是好事也可以是坏事）。

@des #4
@Vhc #6

那下一次可以改成 Long-Term Servicing Distribution

此外我去搜索了一下题目，你后面循环的 body 也是错误的。