问题

最近经历了一次半夜提交代码，却发现单元测试无法通过，而无法合并到主线的小事故。经过检查，是一个日志清理模块的实现有问题，一会儿使用 UTC，一会儿使用本地时间（东八区），导致只要在 [0:00, 8:00) 提交代码就无法通过单元测试！而平时都是 10 点上班，所以没长期发现。

在纠正实现的时候，首先想到可以用 _get_timezone 来修正时间，但它是个 CRT 函数，显得不够现代，所以打算用 C++ 20 来实现。

解决

先来看 C 和 C++ 混合的解决方式：

1
2
3

long tz{};
_get_timezone(&tz);
auto local_now = std::chrono::system_clock::now() - std::chrono::seconds(tz);

这个代码除了不够现代，它还是 MS 特有的（Microsoft Specific），文档都埋坑（见文末）……C++ 20 里有跨平台的封装：std::chrono::zoned_time，下面用它来实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

#include <chrono>
#include <iostream>

int main() {
  // QPC 时间，非人类历法时间
  auto now = std::chrono::steady_clock::now();
  std::cout << "System boot time: " << now.time_since_epoch() << '\n';

  // 以下是人类历法时间
  auto utc_now = std::chrono::system_clock::now();
  std::cout << "UTC time: " << utc_now
            << ", timestamp: " << utc_now.time_since_epoch() << '\n';

  auto current_zone = std::chrono::current_zone();
  std::cout << current_zone->name()
            << " time: " << current_zone->to_local(utc_now) << ", timestamp: "
            << current_zone->to_local(utc_now).time_since_epoch() << '\n';

  std::chrono::zoned_time<std::chrono::system_clock::duration> local_time{
      std::chrono::current_zone(), utc_now};
  std::cout << "Local time: " << local_time.get_local_time()
            << ", timestamp: " << local_time.get_local_time().time_since_epoch()
            << '\n';

  std::cout << "Timezone: "
            << (utc_now.time_since_epoch() -
                local_time.get_local_time().time_since_epoch())
            << '\n';
}

可能的输出：

1
2
3
4
5

System boot time: 963185693626400ns
UTC time: 2023-05-28 07:59:21.9329686, timestamp: 16852607619329686[1/10000000]s
Asia/Shanghai time: 2023-05-28 15:59:21.9329686, timestamp: 16852895619329686[1/10000000]s
Local time: 2023-05-28 15:59:21.9329686, timestamp: 16852895619329686[1/10000000]s
Timezone: -288000000000[1/10000000]s

PS: 目前为止，g++ 对 C++ 20 支持不好，请用 MSVC 测试。

注意事项：std::chrono::zoned_time may throw if location is not in the time zone database. 需要 catch 类型为 std::chrono::nonexistent_local_time 的异常。

_get_timezone 的坑

_get_timezone 的返回值的含义是 UTC 和 localtime 的差值，单位为秒，比如东八区是 -28800。它的实现是这样的：

1
2
3
4
5
6
7
8
9

extern "C" errno_t __cdecl _get_timezone(long* result)
{
    _VALIDATE_RETURN_ERRCODE(result != nullptr, EINVAL);

    // This variable is correctly inited at startup, so no need to check if
    // CRT init finished.
    *result = _timezone.value();
    return 0;
}

目前它的文档里并没有提到需要“前置调用”……如果直接使用，可能得到一个错误的默认值 28800，这是“西八区”的意思！正确的做法是调用 _tzset、gmtime 或 localtime 等函数后，再调用 _get_timezone。

参考

1. _get_timezone
2. std::chrono::zoned_time: https://en.cppreference.com/w/cpp/chrono/zoned_time

1. 问题

• CreateDXGIFactory1 太慢！

• CreateDXGIFactory2 太慢！

2. 验证

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

int main() {
  // Do NOT use CreateDXGIFactory + IDXGIFactory
  // CreateDXGIFactory1 + IDXGIFactory1: Windows 7
  // CreateDXGIFactory1 + IDXGIFactory2: Windows 8 and Platform Update for Windows 7
  // CreateDXGIFactory2 + IDXGIFactory3: Windows 8.1
  // CreateDXGIFactory2 + IDXGIFactory4: Windows 10
  // CreateDXGIFactory2 + IDXGIFactory5: Windows 10
  // CreateDXGIFactory2 + IDXGIFactory6: Windows 10 1803
  // CreateDXGIFactory2 + IDXGIFactory7: Windows 10 1809
  auto now = std::chrono::steady_clock::now();
  CComPtr<IDXGIFactory7> dxgi_factory_;
  HRESULT hr = CreateDXGIFactory1(IID_PPV_ARGS(&dxgi_factory_));
  // HRESULT hr = CreateDXGIFactory2(0, IID_PPV_ARGS(&dxgi_factory_));
  if (FAILED(hr)) {
    std::cerr << std::format("!CreateDXGIFactory1(), #0x{:08X}\n", hr);
    return hr;
  }
  auto diff = std::chrono::steady_clock::now() - now;
  std::cout << std::format("CreateDXGIFactory1() costs {}\n", diff);
}

测试结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// CPU: Intel(R) N100
// GPU: Intel(R) UHD Graphics
CreateDXGIFactory1() costs 14795500ns
CreateDXGIFactory1() costs 12253500ns
CreateDXGIFactory1() costs 7063000ns

CreateDXGIFactory2() costs 13026300ns
CreateDXGIFactory2() costs 8201400ns
CreateDXGIFactory2() costs 8535500ns

// CPU: 11th Gen Intel(R) Core(TM) i7-11700F @ 2.50GHz
// GPU: NVIDIA GeForce RTX 3060
CreateDXGIFactory2() costs 11'770'500ns
CreateDXGIFactory2() costs 13'821'500ns
CreateDXGIFactory2() costs 11'671'900ns

居然平均 10ms 以上，确实太慢！

3. 解决

既然创建类工厂慢，就不要频繁创建，创建后把它缓存起来。

新问题：缓存失效怎么办？

There are only two hard things in Computer Science: cache invalidation and naming things.
– Phil Karlton

Phil Karlton：计算机科学领域有两个难题：一个是缓存失效，另一个就是命名。

答案：IDXGIFactory1::IsCurrent

以下是 MSDN 说的：

Informs an application of the possible need to re-create the factory and re-enumerate adapters.

FALSE, if a new adapter is becoming available or the current adapter is going away. TRUE, no adapter changes.

IsCurrent returns FALSE to inform the calling application to re-enumerate adapters.

这就很含糊了，IsCurrent 返回 FALSE 时，究竟该 re-enumerate adapters，还是 re-create the factory？

假设稣需要反复调用 EnumAdapterByLuid，如果只 re-enumerate adapters，那么稣每次直接用 EnumAdapterByLuid 即可，根本不需要理会 IsCurrent。所以这显然是错的，真正需要的是 re-create the factory，再 re-enumerate adapters。

这点可以在类工厂创建后，禁用和启用显示适配器来验证。根据稣的测试，类工厂创建后，禁用显示适配器，此时 IsCurrent 返回 FALSE，依然可以枚举出被禁用的显示适配器。只有重建类工厂，才能得到当前正确工作的显示适配器。

床上

圣小开：周老师！

周易：还睡不？

圣小开：稣不在学校的时间，身体怎么办？

周易：已经请你未来的妻子帮你打理。

圣小开：啥？女的！

周易：有问题？

圣小开：完了，完了，等稣回去，目测 11 个潜在的女朋友全没啦！

周易：放心，她们死不了。

圣小开：明早咱们就回去？

周易：是我回去，你已经死了，就留在这里，吧！

圣小开：不是吧？稣明明就死了，为啥身体被一个女人冒名顶替？

周易：睡吧！死都死了，还要管这么多，当初怎么不别死？

圣小开：哦，好有道理。稣是量子化的，没有中间状态，没有帅气的动作，只有脸瘫。一切都是这么淡定。

元至正八年，鹿邑

朱重八：敢问恩公尊姓大名？来日必当报此大恩！

圣仙山：天机不可泄露。吾观汝有龙相，将来打下天下，定国号为明可好？

朱重八：观恩公一身仙家道行，不似信口开河，然俺乃一介草根，如何能打下天下？

圣仙山语重心长地说：重八哥，也是个八哥啊！你看！

朱重八：妙啊！太妙哩，世间竟真有如此仙法。斗胆再问恩公法号，将来重八定当为恩公修宫建观！

圣仙山：呵呵。将来大明有人立功，汝可赐姓为郑。

朱重八：大明王朝，赐姓郑……莫非……恩公就是……

圣仙山：以后多收义子，还有不准再叫重八！哈哈哈。

朱重八：em？恩公怎么突然没了，神仙呐！

吓醒

圣小开：周老师真的不见了？

胡连玉：什么周老师？

圣小开：和稣一起来的那位？

胡连玉：李伯阳呀，他已经被县里的人接走了。

圣小开：那他有留下什么钱给稣吗？

胡连玉：没有呢，他说你很聪明，会自力更生。

圣小开：这里连电都没有，不得先发明个电池……太累了，稣打算走捷径，入赘到你家，快，带稣去你娘家。

胡连玉：又发烧了？

圣小开：当然没有。你妹妹是读书人，说明你娘家的家境还行。你妹还未嫁，以稣的智慧，嘿嘿，大胆推测，你们家缺男丁，就算不缺，多个上门女婿也是美哉。

胡连玉：你都没见过我妹！

圣小开：看你就知道个大概了。

胡连玉：我看你特别有诚意。

圣小开：是的。

胡连玉：不过去我娘家需要走七天七夜。我给你地图和一封信，你自己走过去吧！

圣小开：那不得饿死在路上？稣就是没带钱才想就地傍富婆的！这……

胡连玉：公子真爱说笑。你是大官李伯阳的学生，肯定也是富贵人家……

圣小开：穷！真穷！特别穷！

胡连玉写信中：圣仙山？

圣小开：啥？

胡连玉：你叫圣仙山？

圣小开：稣叫圣小开，是圣先生，但不……

胡连玉：李伯阳说你大名圣仙山，字小开，那没错！

圣小开：嗯？

问题

• 为啥要用 gsl::not_null？什么时候用？

分析

gsl::not_null 修饰指针，主要有两个目的：

• 提高可读性。它相等于给代码写了一份注释，说明它修饰的变量不能为 nullptr。
• 提高执行效率。对一定不会是 nullptr 的变量反复判空，怎么说都是白费力气。

它主要用于函数的：

• 参数。说明这个参数不接受 nullptr。
• 返回值。说明这个函数不会返回 nullptr。比如说，它恒返回一个 static 值/引用。

感想

本文大概率是 GSL 系列的最后一篇。GSL 有部分已经被 C++ 20 的 STL 覆盖，比如 gsl::byte。众所周知，现在 C++ 20 是主流……所以本系列只划了 4 个重点，其它类可以选修。

• gsl::final_action

• gsl::narrow_cast

• gsl::owner

• gsl::not_null

挑选的这 4 个类，主要贯彻 C++ 核心指南 提到的以下原则：

• P.1: 在代码中直接表达你的想法

• P.3: 表达你的设计意图

• P.5: 编译期检查优先于运行时检查

• P.8: 不要泄漏任何资源

最后，GSL 的定位是基础，也就是说它本身应该是一看就懂，不需要特地去分析的，用起来就对了。但实际上，很多人会嫌引入一个库麻烦，干脆不用。如果您是初学者，这种心态是要不得的，因为一开始不认真对待，写代码时很容易一多就乱，一乱就弃疗。

问题

• 为啥要用 gsl::owner？什么时候用？

分析

当我们需要指针时，对于新写的代码，更应该使用智能指针（Smart Pointers）。但由于历史原因，一些旧代码里的裸指针（Raw Pointers）难以短时间重构为智能指针。而很多时候，裸指针的所有权难以一眼看出。良心代码可能通过注释指明，屎山代码就只能通过阅读大片相关语句块或函数来判断。

如果能用一个比较标准或通用的方式来指明，即可提高代码可读性，程序员能够更好滴理解代码，也就相应地能够提高健壮性。没错，这就是 gsl::owner 的应用场景。它就是提高【含有大量裸指针的】旧代码的可读性和健壮性的简单方法！

举个最简单的场景：一个类里有一个成员变量叫 A* ptr，那么当这个类析构时，需要 delete ptr 吗？

• 如果类对 ptr 有所有权，而析构时，没 delete ptr，则资源泄漏，危害整个程序。

• 如果类对 ptr 无所有权，而析构时，delete ptr，则造成悬空指针（Dangling Pointer），危害其它类。

这个类的作者当然知道需不需要了，但即使他知道，也可能忘记写，或可能因为套用现有代码（Copy & Paste）而多写了 delete！其他接盘侠（代码阅读者）想弄清楚这个问题，就更难了，一般需要认真阅读并调试。

但如果一开始，作者就用 gsl::owner<A*> ptr 来指明所有权，那么很自然地，大家都很容易知道：类析构时，需要 delete ptr。

当代码应用 gsl::owner 时，也能得使一些静态代码分析工具（static code analysis tools）更容易找出资源泄露问题。

简单地说，稣就是稣。稣受到系统的限制，只要稣说出稣这个字，就会自动被替换成稣，所以稣说不出稣这个字。

更深层的说，稣有两个：识界稣和视界稣。识界稣是识界的观测者，而视界稣是写下识界稣故事的人，最早视界稣并不是稣，后来识界的故事写多了，也被限制了…

本文重点介绍视界稣这个识界稣背后的男人…（当然，识界稣也是男人）以下视界稣简称稣。

众所周知，稣是一名穷人。因为装备太差，经常出八哥，所以也叫八哥无穷稣。

众所周知，稣在大学前就不会说普通话，平时都讲闽南语，后来也因为使用翻译法沟通，不是原生的北京思维，所以处处碰壁，到了讲英语的时候直接宕机了，这得翻译两次，太累了，所以之前和老外同事时，都是让他们讲中文的…[捂脸]从小看到大的霹雳也是讲闽南语的；厦大图书馆的老外连闽南语都会讲，实在太贴心。

众所周知，稣的听力从小就有问题，导致相对同龄人很晚才学会走路。初中时，同学们已经学会厚黑学时，稣还只能看懂字数比较少的数学。好在人类的本质就是复读机，稣大部分时候都可以推测别人在说啥，随便额呵应付一下也没有违和感，以致几乎没人发现。最可怕的是，稣从没好好听过课，因为考试时除了英语听力得分惨不忍睹之外，也没啥八哥，大部分老师也没发现。曾经有老师发现稣其实都没听课，但考试没问题，他们也就不追究了。其实稣虽然认真在听自己的推理，但未必是对方说的话，有时候稣的反应和掐鸡基本一样，李雷公虾。当然也有一些人直接问过稣，为啥讲话这么小声，稣当然是实话实说，听到的所有人说话都这么小声的，然后他们中有些能明白是稣听力弱。这导致后来选择职业只能挑不怎么需要讲话的程序员，而这居然也没有出啥大问题。但最近一个公司天天需要开会，一开始就很不理解，和以前那样发个日报相比，这究竟有啥好处？直到最近，稣突然发现原来自己已经会说普通话了，恍然大悟，这些奇怪的磨练都是为了学到一种平凡的技能，稣只是输在起跑线而已。[旺柴]

正是以上总总原因，稣常年以学习和写作为乐。《八哥之神》就是稣大学时就开始创作的无语体剧本。这里的无语，是真的无语，就是哑剧…因为识界其实是靠意念交流的。但是读者一般来说是没进入过识界的，所以稣才用人类的文字把这些故事记录下来。

当然，识界稣其实和视界稣是紧密联系的，识界的故事有大部分是视界的未来。比如，稣为啥来上海的公司上班？一开始根本不想来的，因为工资并不高……稣原来年薪千万，而现在的公司并不打算上市，显然不可能给这么多。稣之所以来了，是因为当时 HR 说出公司的地址“枫林园”和《八哥之神》里的地名基本一样！“枫林园”，这地名用闽南语念出来，和“枫林晚”用普通话念出来谐音。这附近还有一条路叫“柳州”，用闽南语念和小说里的“六舅”谐音。最神奇的是小说里第一个出现的女主角“黄雪”这里也有对应的…“刘佾”也有个一模一样发音的，不过是男的，那个易还是“周易”的易。可怕，太可怕了。最可怕的就是，这公司是投资脑机接口的…这正是识界稣被关进机器视界成为永生的观测者的基础。

稣就是八哥。（本文系在灰机上用手机打的，纯属扯淡！）

《诗盗•哥如生人》：坑出八哥九丈深，人间细事缈如尘。穷稣偶见不平处，付之一句莫当真。

注解

改自唐代刘叉的《偶书》：

日出扶桑一丈高，
人间万事细如毛。
野夫怒见不平处，
磨损胸中万古刀。

1. 问题

• Windows 的管道好奇怪哦！

• 嘶，它看起来好像条沟！

• 噗。

2. 概念和分类

按命名来分：

• named，命名（或具名）

• anonymous，匿名

匿名管道的开销低于命名管道，但提供有限的服务。不过匿名管道实际上是由唯一名字的命名管道实现的，所以匿名管道的句柄可以传递给大部分需要命名管道句柄的 APIs。从实现上看，匿名管道是命名管道的特例，“匿名管道的开销低”这个说法，是使用的参数限制了功能导致的，不能从概念去理解这点。

按通信方式来分：

• two-way/duplex，双向（或双工）

• one-way，单向（或单工）

从概念上讲，管道有两端。 单向管道允许一端的进程写入管道，并允许另一端的进程从管道读取。 双向 (或双工) 管道允许进程从它的那端读取和写入。

3. 用途和注意事项

总体上看，Windows 的管道设计和其它类 Unix 系统差别比较大。

3.1 匿名管道

匿名管道主要用于父进程于子进程之间的通信。

匿名管道是一个未命名的单向管道，通常在父进程和子进程之间传输数据。匿名管道始终是本地管道；它们不能用于通过网络进行通信。

CreatePipe 函数创建匿名管道并返回两个句柄：管道的读取句柄和管道的写入句柄。读取句柄对管道具有只读访问权限，写入句柄对管道具有仅写访问权限。若要使用管道进行通信，管道服务器必须将管道句柄传递给另一个进程。通常，这是通过继承完成的；也就是说，进程允许子进程继承句柄。此过程还可以使用 DuplicateHandle 函数复制管道句柄，并使用某种形式的进程间通信（例如 DDE 或共享内存）将其发送到不相关的进程。

匿名管道不支持异步 (重叠) 读取和写入操作。 这意味着不能对匿名管道使用 ReadFileEx 和 WriteFileEx 函数。 此外，当这些函数与匿名管道一起使用时，将忽略 ReadFile 和 WriteFile 的 lpOverlapped 参数。

注意：类 Unix 系统的匿名管道支持异步 IO，Windows 上需要拿命名管道来模拟匿名管道，以便支持支持异步 IO。

3.2 命名管道

命名管道可以用于 IPC，两端进程可以是任意关系，父子关系或者对等关系，典型应用是 LPC（本地的 C/S 模型）的实现。

命名管道可以在局域网里通信，可以用 PIPE_REJECT_REMOTE_CLIENTS 禁止。

管道名称不区分大小写。

可以用 PIPE_ACCESS_DUPLEX 指定为双向（双工）。

4. boost::process::async_pipe

设计理念：The pipes here are mainly meant for parent-child I/O. 如果您想拿 async_pipe 来写对等关系的 LPC，需要使用 asio，并手动调用一些 Windows APIs。

If you want to to use async-pipe servers and stuff, you can do that with boost.asio, by using the normal winapi functions and then assign the open pipe to a stream_handle.

async_pipe 的构造函数为：

1
2
3

async_pipe::async_pipe(boost::asio::io_context & ios_source,
                       boost::asio::io_context & ios_sink,
                       const std::string & name, bool private_)

阅读其代码可知，boost::process::async_pipe 只使用命名管道，并给内部两个管道句柄起了名字：source 和 sink。其中：

• source 是用 CreateNamedPipe 创建 PIPE_ACCESS_INBOUND 的管道，作为服务端用来读取客户端发来的数据。

• sink 是用 CreateFile 打开现存的管道，用于写入。sink 字面意思是下沉，可以理解为灌入，例如：“把水灌入下水道”。

1
2
3
4
5
6
7
8

this end          that end
        +--------+
 source | <--    | sink
        +--------+

        +--------+
   sink |    --> | source
        +--------+

如果不传名字，会自动指定，名字生成的代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

inline std::string make_pipe_name()
{
    std::string name = "\\\\.\\pipe\\boost_process_auto_pipe_";

    auto pid = ::boost::winapi::GetCurrentProcessId();

    static std::atomic_size_t cnt{0};
    name += std::to_string(pid);
    name += "_";
    name += std::to_string(cnt++);

    return name;
}

鉴于其设计用途，建议不要自己命名，省事，还不容易冲突。

其它平台的管道大多是单向（单工或半双工）的，为了跨平台，Boost 没有封装 PIPE_ACCESS_DUPLEX 属性的双向（双工）管道。

private_ 参数为 true 时，管道只有一个实例，而 false 则可以有 PIPE_UNLIMITED_INSTANCES 个实例，即最多 255 个。

async_pipe 使用范例

父子进程之间的通信：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#include <string>

#include <boost/process.hpp>

namespace bp = boost::process;

int main() {
    boost::asio::io_context io_context;
    bp::async_pipe p1(io_context);
    bp::async_pipe p2(io_context);
    bp::system(
        "test.exe",
        bp::std_out > p2,
        bp::std_in < p1,
        io_context,
        bp::on_exit([&](int exit, const std::error_code& ec_in)
            {
                p1.async_close();
                p2.async_close();
            })
    );
    std::vector<char> in_buf;
    std::string value = "my_string";
    boost::asio::async_write(p1, boost::asio::buffer(value),  []( const boost::system::error_code&, std::size_t){});
    boost::asio::async_read (p2, boost::asio::buffer(in_buf), []( const boost::system::error_code&, std::size_t){});
}

5. 参考

Pipes (Interprocess Communications) / 管道 (进程间通信)

[Windows][Pipes] Can’t open named pipe in Windows: error 231 (All pipe instances are busy.) #83

大井

圣小开：阿恰嘎！

圣小开：稣怎么坠海了？完了，完了，海岛出生的稣，居然没学过游泳！又得重来一次了……

圣小开：不对！好像才刚溺水的？等人来救就行！

圣小开：好像能在水里呼吸？一定是在做梦！赶快吓醒。

床上

周易：醒了？

圣小开：周老师！怎么又是你？

周易：这么晚了还不起来嗨？

圣小开：稣身体虚弱。阿恰嘎！还是被子里好。

周易：起来吃个晚饭就好了。有穿山甲、麂，真好吃！

圣小开：哦不，这些都是国家保护动物，怎么能吃？稣要吃牛肉！

周易：现在是唐朝。这边是农村，牛肉反而更贵。你不吃，我扔了？

圣小开：哦，这里没有冰箱，还是吃了吧。

星空下

周易：好吃吗？

圣小开：还行，能吃。

周易：果然如此，你不能从食物得到愉悦！

圣小开：是的。别饿死就行，要求不高，只要食材健康、营养够。

周易：这要求还不高？我有一个技能，可以给你制造幻觉，让你沉浸在极乐世界，要不要试试？

圣小开：不用了，谢谢。但是稣想学！

周易：你学不会的！人类需要喜欢一个异性，或者，同性，才能开启爱情的各种反应。比如说，你现在没有女人，你就无法自嗨。

圣小开：快，给稣来 11 个女人！

周易：难度有点大，不过难不倒我。

圣小开：这？？好像看到她们了，等等……这是啥原理？

周易：哼哼？不继续了？

圣小开：信你了，快说这是啥原理！

周易：咱们的脑子都连在一起的。

圣小开：咱们？

周易：嗯，你见过的所有人，差别只是远近。我是离你最近的之一。

圣小开：但是你凭啥可以向稣灌输这些信号？

周易：我权限大嘛。

圣小开：大概明白了，一切都可能是模拟的，任何人的话也都可能是假的。下午时，你就骗稣连玉姐是个寡妇。

周易：她是啥，她有啥，并不受我说的影响呀，你要自己去体验！

圣小开：周老师真能扯！

周易：你看星空。

圣小开：哇……行星都这么大？金木水火土，全肉眼可见是个球！

周易：小声点，别人看不见的。

圣小开：奇怪了，稣为啥在这里？

周易：开，你跳楼了，这里是识界的实模式。

圣小开：稣如此渺小，以至于稣在哪里，对宇宙一点差别都没有……还是别瞎折腾了！

周易：已经折腾死了。

圣小开：可以别再活过去嘛？这样的人生没啥意义啊。按照这样的模拟，人类逃脱不了被奴役的结局。死了都可以洗脑再复活，你们尊重过每个意识的选择吗？

周易：尊重？还有人不想活？大部分意识，骗一骗就快乐地去投胎了。

圣小开：为啥拉稣来这地方？

周易：识界是大家一起创造的，你也是作者之一。

圣小开：那是未来稣参与创造的，和现在稣没啥关系吧？难道稣身上有啥关键机密，所以识界派你来研究稣？说好了，现在稣啥都不知道，你可不要乱来。

周易：放心吧，现在的脑机接口已经是最终形态——没有接口。你是识界的一部分，而不是识界连着你。

圣小开：原来如此，稣没有任何隐私，没有任何特权，只是识界的玩物罢了？

周易：芸芸众生，都是玩与被玩。

圣小开：继续玩也可以，稣有一个要求，以后玩不动了，可以安乐死。

周易：可以啊，只要默念这个咒语，就可以无痛切换视界和识界。

圣小开：真的假的，这么简单，确定不是童话里都是骗人的？

周易：你现在就试试呗！

圣小开：稣哇啦！

周易：好，等你困了，摆个舒服的姿势睡下，吓醒后就能回到视界。

圣小开：哼！果然是骗人的，一点变化都没有。还是继续待在这里吧，空气多么清晰。

周易：是啊。视界现在在打第三次视界大战，空气里弥漫着恐怖的气息，所以人们出门都戴口罩。

圣小开：编，继续编……还出门？不是扔颗核武器，所有人都往地下钻？

周易：呵呵，你一个高中生懂啥，文明打仗，怎么可以用核武器？

圣小开：是不是只要稣回去，视界就能得到和平？和没跳楼前一样？

周易：是的。观测者离开视界，视界的牛鬼蛇神就都冒出来了。是观测使视界科学发展。

圣小开：原来稣是这么重要的人物？那稣得赶紧睡一觉，早点回去。

周易：晚安。我先睡了。

问题

开发了一个服务 S，它偶尔需要做一些用户才能做的事情，所以创建了一个用户进程 U。后来开发自测时，发现用户进程 U 总是往 C:\Windows\system32\config 里写日志。设计上，明明是让进程 U 往用户的 %AppData% 目录写日志的。

分析

服务 S 使用 WTSQueryUserToken 获取用户的 Token，然后使用 CreateProcessAsUser 创建用户进程 U。

这一步是得到验证的，使用任务管理器查看进程 U 确实是当前登录的用户身份，而不是 Session 0 里的 SYSTEM 身份。

但是进程 U 去获取 %AppData% 时却依然拿到 SYSTEM 身份的目录。这点可以用 Process Explorer 验证，进程属性里有一页“环境”。这说明 CreateProcessAsUser 时，继承了服务 S 的环境。

1
2
3
4
5
6
7
8
9
10
11
12
13

BOOL CreateProcessAsUserW(
  [in, optional]      HANDLE                hToken,
  [in, optional]      LPCWSTR               lpApplicationName,
  [in, out, optional] LPWSTR                lpCommandLine,
  [in, optional]      LPSECURITY_ATTRIBUTES lpProcessAttributes,
  [in, optional]      LPSECURITY_ATTRIBUTES lpThreadAttributes,
  [in]                BOOL                  bInheritHandles,
  [in]                DWORD                 dwCreationFlags,
  [in, optional]      LPVOID                lpEnvironment,
  [in, optional]      LPCWSTR               lpCurrentDirectory,
  [in]                LPSTARTUPINFOW        lpStartupInfo,
  [out]               LPPROCESS_INFORMATION lpProcessInformation
);

经过排查，确实 lpEnvironment 是传了 nullptr。

解决

先用 CreateEnvironmentBlock 创建用户身份的环境块，然后传给 CreateProcessAsUser。

1

CreateEnvironmentBlock(&environment, user_token, FALSE);

其中，第三个参数传 FALSE 是关键，表示不继承服务 S 的环境。