2

在多台机器上“部署”这个问题的解决方案时，我注意到一些单核机器的结果很糟糕（例如，解决方案在英特尔原子上失败了）。

这里发生的事情如下。我打电话SetWinEventHook(...)来获取控制台更改的回调。由于超出上下文的通知，事件处理和控制台上的进一步更改之间没有同步，所以虽然多核机器做得很好（顺便说一句不是完美的），但单核机器却把这弄得一团糟。

所以我继续打开 In-Context 通知，因为根据 msdn 这应该是同步的。在 c# 中，这就像要求无限不可能驱动器，所以我在 C 中创建了一个简单的 dll，它可以完成肮脏的工作，并与 c# 中的 dll 对话。到目前为止，一切都很好。

事实证明，回调发生在 conhost.exe 中，而不是拥有控制台的进程。现在这提出了一个问题，因为在回调中我找不到在conhost.exe 的上下文中访问控制台输出缓冲区的方法。或者更准确地说，我似乎无法找到处理它的方法。以下是可用的：控制台窗口的句柄、控制台应用程序和 conhost.exe 的进程 ID 以及控制台应用程序的管道。

这是我到目前为止所尝试的：

  1. 使用GetStdHandle(...), 导致无效句柄（在 conhost.exe 的上下文中有意义）
  2. 使用CreateFile("CONOUT$"...)_
  3. 使用管道让控制台应用程序从输出缓冲区读取，会导致死锁。我怀疑一种用于防止在写入时读取的锁定机制，这是有道理的。
  4. 复制输出缓冲区句柄并通过管道传递它。没有乐趣，因为控制台句柄不能复制到外部进程。
  5. 将 conhost.exe 进程附加到它所服务的控制台进程的控制台，然后执行 CreateFile 操作。好的，这是我最喜欢的一个，但它也不起作用，因为AttachConsole(...)块，类似于 3。

有人对接下来要尝试什么有任何想法吗？我的 c/c++/winapi 技能充其量是中等水平，所以我很可能忽略了一些东西。好吧，一个明显的做法是将整个事情扔到一边，然后轮询输出缓冲区以进行更改，但我认为这是最后的选择。我假设 MS 足够聪明，可以确保 In Context 或 Out of Context 事件实际上是可用的，因此我必须遗漏一些东西。

4

0 回答 0