Skip to content

YukiNative 踩坑记——Windows 的消息队列

Published: at 01:17

最近在实现 YukiNative,也算是顺风顺水虽然一直在现学 C#。对于 YUKI 中大部分平台依赖的代码都解决地差不多了。但是到了我自己加的某一个功能时,却出了大麻烦……

ToC

简述

功能本身说起来很简单:让 YUKI 跟随游戏窗口同步最大化/最小化。但仔细想想就会发现这其实是一个很平台依赖的功能需求。在 Node 中,我是这么实现的:

import * as ffi from 'ffi'
const user32 = ffi.Library('user32.dll', {
SetWinEventHook: ['uint32', ['uint32', 'uint32', 'uint32', 'pointer', 'uint32', 'uint32', 'uint32']],
UnhookWinEvent: ['bool', ['uint32']]
})
const EVENT_SYSTEM_MINIMIZESTART = 0x0016
const EVENT_SYSTEM_MINIMIZEEND = 0x0017
export function registerWindowMinimizeStartCallback(
handle: number,
callback: () => void
): boolean {
return doRegisterEventHook(EVENT_SYSTEM_MINIMIZESTART, handle, callback)
}
export function registerWindowMinimizeEndCallback(
handle: number,
callback: () => void
): boolean {
return doRegisterEventHook(EVENT_SYSTEM_MINIMIZEEND, handle, callback)
}
function doRegisterEventHook(
event: number,
handle: number,
callback: () => void
): boolean {
const eventProc = ffi.Callback('void',
[ffi.types.ulong, ffi.types.ulong, ffi.types.int32, ffi.types.long, ffi.types.long, ffi.types.ulong, ffi.types.ulong],
(hook: number, event: number, hwnd: number, obj: number, child: number, thread: number, time: number) => {
callback()
})
const num = user32.SetWinEventHook(event, event, 0, eventProc, handle, 0, 0)
process.on('exit', () => {
if (num !== 0) {
user32.UnhookWinEvent(num);
}
eventProc;
})
return num !== 0
}

其实这里也藏着一个坑,就是 process.on('exit') 的地方。为了防止回调在被调用之前就被 GC,我们需要额外引用一下 callback

言归正传。不难发现,要做到这个功能,其中一种方法就是通过 SetWinEventHook,也就是上文中用到的方法,配合回调函数实现。在 Node 下,这种方法可谓是开箱即用,没有耗费我太多的时间。纵使对 Windows API 一窍不通,也不算特别困难。因此当我移植到这一步时,我满心以为这项工作很快就能结束。

然而事实证明,我错了。完成这项移植,我们需要稍微了解一些偏底层的知识。虽然只是一点,但需要就是需要,逃不过的。

YukiNative 简介

在说明之前首先来简单介绍一下 YukiNative 的存在。[YukiNative](https://github.com/Yesterday17/YukiNative) 是为了替代 YUKI 中平台依赖部分而独立出来的纯 Windows 应用程序,其目标是替代目前 YUKI 中所有和 Windows (偏)底层打交道的部分,包括 DLL 调用、进程(退出)状态监听、以及我加的窗口检测。

YukiNative 使用了 .NET Framework 4.7.2,但理论上也可以在 .NET Core 2.0 下编译。

控制台程序与图形界面应用

众所周知,在 Windows 下,你可以通过钩子捕获/修改很多东西。这里我们常常会忽视一个概念:钩子是针对 GUI 程序而言的。

想象没有窗口用户界面的时代,那时候只有控制台,但是——如果用窗口的概念去理解的话,也可以说是只有一个窗口。并且当时的事件也很少:键盘事件恐怕是唯一常用的存在了。

然而到了现在,窗口的出现带来了大量的新概念,包括窗口状态、窗口位置等,随之而来的也就出现了大量的事件。这些事件通过消息的形式传递出去,并最终落入需要的窗口手中。

发现了吗?其中没有控制台程序的位置

原因说起来也简单,控制台程序是另一种程序形式。它们没有图形界面(或许有字符界面),与我们今天见到的那些应用们格格不入。

同样如此,所以图形界面那一套默认是没有带到控制台应用中去的。

消息队列

为了应对图形界面带来的这么多消息,消息队列就出现了。

消息队列是针对每一个线程而言的(因为一个线程可能就对应着一个窗口),负责存放线程需要处理的消息。

我们可以通过 GetMessagePeekMessage 来获取消息队列中的消息。唯一的区别就在于前者阻塞,而后者非阻塞

消息循环

通常的图形界面应用会通过消息循环Message Loop)的方式读取消息队列中的内容。也就是一个大循环,里面用 GetMessage 或者 PostMessage 读取消息,并且通过 TranslateMessageDispatchMessage 进行处理。

于是……

还记得上面的 SetWinEventHook 吗?我们现在知道了事件的传递是通过消息进行的,那么我们想要的最大/最小化事件也就一定蕴含在了事件之中。SetWinEventHook 帮我们声明了需要的事件,Windows 将事件对应的消息送到了线程的消息队列中,而我们却一直没有去取,导致了没有注册成功的假象

这种假象是很致命的,和带有垃圾回收的语言结合起来尤甚。你会怀疑出问题的地方究竟在哪里,从而忽视了事情的本质。

解决

成功定位问题之后,解决起来就简单多了。主要部分如下:

public static class MessageLoop {
private static readonly Queue<Tuple<Events, uint, Action<int>>> Tasks =
new Queue<Tuple<Events, uint, Action<int>>>();
public static TaskCompletionSource<int> AddHook(Events @event, uint pid) {
var promise = new TaskCompletionSource<int>();
Tasks.Enqueue(new Tuple<Events, uint, Action<int>>(@event, pid, i => promise.TrySetResult(i)));
return promise;
}
public static void Run() {
while (true) {
if (PeekMessage(out var msg, 0, 0, 0, 1)) {
Console.WriteLine(msg);
if (msg.Message == WmQuit)
break;
TranslateMessage(ref msg);
DispatchMessage(ref msg);
}
else if (Tasks.Count > 0) {
while (Tasks.Count > 0) {
var task = Tasks.Dequeue();
var hook = SetWinEventHook(
task.Item1,
task.Item1,
IntPtr.Zero,
WinEventCallback,
task.Item2,
0,
0);
task.Item3(hook);
}
}
Thread.Sleep(0);
}
}
const uint WmQuit = 0x0012;
[StructLayout(LayoutKind.Sequential)]
private struct MSG {
IntPtr Hwnd;
public uint Message;
IntPtr WParam;
IntPtr LParam;
uint Time;
POINT Point;
}
[StructLayout(LayoutKind.Sequential)]
private struct POINT {
long x;
long y;
}
[DllImport("user32.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.StdCall)]
private static extern bool GetMessage(ref MSG msg, int hWnd, uint wMsgFilterMin, uint wMsgFilterMax);
[DllImport("user32.dll")]
private static extern bool PeekMessage(out MSG msg, int hWnd, uint wMsgFilterMin, uint wMsgFilterMax,
uint wRemoveMsg);
[DllImport("user32.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.StdCall)]
private static extern bool TranslateMessage(ref MSG msg);
[DllImport("user32.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.StdCall)]
private static extern IntPtr DispatchMessage(ref MSG msg);
[DllImport("user32.dll", SetLastError = true)]
private static extern int SetWinEventHook(Events eventMin, Events eventMax, IntPtr hmodWinEventProc,
WinEventProc lpfnWinEventProc, uint idProcess, uint idThread, uint dwflags);
[DllImport("user32.dll", SetLastError = true)]
private static extern int UnhookWinEvent(int hWinEventHook);
}
}

完整代码位于 https://github.com/Yesterday17/YukiNative/blob/master/YukiNative/services/Win32.cs

结语

撞坑撞了一晚上的存在吃了没文化的亏。从完全不知道消息队列这个东西到渐渐明白其中的内容,度过了一段非常有意义的时光(笑

上面反复加粗线程,其实这里有个说得不是特别详细的地方:不同线程的消息队列不同。而由于 C#TaskThread 的语法糖,因此这种类似 Promise 的东西你也是没法用的。你只能乖乖地把所有东西都放到一个线程里,也就是上面代码里 AddHook 的诞生原因了。

在整个从无到有的过程中,下面的这些文章给了我很大帮助,故在文末列出(排名代表顺序)。

鸣谢

  1. https://gist.github.com/fjl/4080259
  2. https://stackoverflow.com/questions/15849564/how-to-use-winapi-setwineventhook-in-python
  3. https://docs.microsoft.com/en-us/windows/win32/learnwin32/window-messages

Previous Post
我是我自己——论获取 HTTPS 证书时的验证步骤
Next Post
一次 HSTS 策略配置的排错之旅