Windows GUI在内部做了什么？ [英] What did Windows GUI do in deep inside?

问题描述

- 今天我研究了一些新东西，其中一部分让我用Process和Thread做了一些事情。

- Today I researching something new and one its part took me to do something with Process and Thread.

- 我创建了一个工具从进程名称获取所有线程，结果是：

- I made a tool get all threads from process name, the result are:

- 第一个程序是简单的控制台应用程序，没有错。

- The first program is simple console app, nothing wrong here.

- 第二个程序是最简单的winapi GUI，最后是最简单的WinForm。在我的代码中，程序2和3不构成创建新线程，但正如您所见，一个是4个线程，另一个是8个线程。

- The second program is simplest winapi GUI and last is simplest WinForm. Inside my code, the program 2 and 3 consist nothing to create new thread, but as you saw, one is 4 threads, other is 8 threads.

- 了解Windows上的编程微软通常只在一个线程上创建GUI，因为它的复杂性。实际上他们在内部做了什么？

- With my understand about programming on Windows is the microsoft usually just create the GUI on only one thread because the its complex. So actually what did they do in deep inside?

推荐答案

不，由于交叉线程怪癖与之交互，GUI只停留在一个线程上消息队列。这并不意味着应用程序必须保持单线程。

No, the GUI only stays on one thread because of cross thread quirks interacting with the message queue. This doesn't mean that the application has to stay single threaded though.

我想问的是，你是如何检测进程中的线程的？你看，即使一个控制台应用程序显示额外的工作线程，所以我更惊讶你的控制台应用程序只看到一个。对于32位应用程序，Visual Studio 2017显示
有两个额外的线程，其中64位应用程序有3个额外的线程。这不是GUI流程的深层工作，这只是我能看到的流程的工作原理。

The thing that I want to ask, how did you detect the threads in a process? You see, even a console application shows extra worker threads, so I'm more surprised that your console application only saw one. For 32 bit applications, Visual Studio 2017 shows that there are two extra threads, where 64 bit applications have 3 extra threads. This isn't the deep workings of a GUI process, this is just the workings of a process from what I can see.

这篇关于Windows GUI在内部做了什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！