先看一段引文，出處不甚清楚,，但肯定是一本紙質(zhì)出版物,。
> 程序啟動后就執(zhí)行的那個線程稱為主線程（primary thread），主線程有兩
> 個特點,，第一,，它必須負(fù)責(zé) GUI（Graphic User Interface）程序中的主消息循
> 環(huán)。第二,，這一線程的結(jié)束（不論是因為返回或因為調(diào)用了 ExitThread()）會
> 使得程序中的所有線程都被強迫結(jié)束，程序也因此而結(jié)束,。其他線程沒有機會
> 做清理工作,。
我看書的時候很少字斟句酌，一般都是只了解個大概,，而像這樣的句子就基本屬于我無視的內(nèi)容,。不過，在一個偶然的機會,，我注意到了這句話,，并有了以下這篇評論。
先說結(jié)論：句中所提到的“主線程的兩個特點”,，基本不靠譜,。
> 第一，它必須負(fù)責(zé) GUI（Graphic User Interface）程序中的主消息循環(huán),。
之所以說這句話不靠譜,，是因為它過度地限制了主線程的功能。在我的印象中,，靈圖天行者 4.0 以前的版本（含）中,，主線程是一個調(diào)度器，用于調(diào)度其余的工作線程,，而 UI 線程則亦是這些工作線程中的一個,。換句話說,，主消息循環(huán)可以不在主線程之中。
> 第二,，這一線程的結(jié)束（不論是因為返回或因為調(diào)用了 ExitThread()）會使得程序中的所有線程都被強迫結(jié)束,，程序也因此而結(jié)束。
這句話半對半錯,，因為如果在主線程中調(diào)用 ExitThread 的話,，其它線程是不會退出的，因此程序也不會結(jié)束,?？紤]以下代碼：
C++代碼
- #include <Windows.h>
-
- DWORD WINAPI ThreadProc(PVOID param)
- {
- for (;;)
- {
- Sleep(1000);
- }
- return 0;
- }
-
- int main(void)
- {
- HANDLE hThread = CreateThread(NULL, 0, ThreadProc, NULL, 0, NULL);
- Sleep(1000);
- ExitThread(0);
- return 0;
- }
程序運行后，main 所在的線程被 ExitThread 結(jié)束,，但 ThreadProc 的線程卻會一直運行,。對于這個問題，我在《Windows 編程札記》中的一段話能夠很好的解釋,，如下,。
---------- 傳說中的分隔線 ----------
那么，就讓我們來探索一下進(jìn)程正常結(jié)束的過程吧,。為了避免一切不必要代碼的干擾,，我選擇了一個空無一物的骨架程序。
C++代碼
- #include <Windows.h>
-
- int WINAPI WinMain(
- HINSTANCE hInstance,
- HINSTANCE hPrevInstance,
- LPSTR lpCmdLine,
- int nShowCmd)
- {
- return 0;
- }
如你所見,，這個程序?qū)嵲谑菬o愧于“骨架”這個稱號——那真是除了骨頭就是架子了,。
從表面上來看，這個 WinMain 就是程序的入口,。當(dāng)它返回（return 0;）之后,，我們的進(jìn)程就結(jié)束了。當(dāng)然,，事實肯定沒有看起來的這么簡單,，因為編譯器是很樂于偷偷做好事的，而且做了好事還有拒不留名的習(xí)慣,。
現(xiàn)在讓我們編譯這段代碼,，并使用 WinDbg 來調(diào)試這個程序。我們不設(shè)置任何斷點,，直接讓程序運行到結(jié)束,。在這個時侯，程序的調(diào)用堆棧信息會是下面這個樣子：
WinDbg 輸出
- 0:000> k
- ChildEBP RetAddr
- 0012fdc4 7c92e89a ntdll!KiFastSystemCallRet
- 0012fdc8 7c81ca3e ntdll!ZwTerminateProcess+0xc
- 0012fec4 7c81ca96 kernel32!_ExitProcess+0x62
- 0012fed8 004012a1 kernel32!ExitProcess+0x14
- 0012fee4 0040148d skeleton!__crtExitProcess+0x17
- 0012ff28 004014b7 skeleton!doexit+0x113
- 0012ff3c 0040114f skeleton!exit+0x11
- 0012ffc0 7c816ff7 skeleton!__tmainCRTStartup+0x121
- 0012fff0 00000000 kernel32!BaseProcessStart+0x23
真相終于大白于天下,。很顯然,，編譯器把 kernel32.dll 的 ExitProcess API 藏到了 WinMain 的后面，使得我們的 skeleton.exe 進(jìn)程最終得以退出,。如果你對如何封裝 ExitProcess 的細(xì)節(jié)感興趣的話,，那么可以深入研究 Visual Studio 附帶的 C runtime 源代碼中的 crt0.c 文件,，這里就不再多介紹了。
