最近工作中遇到Window Ghosting這個問題， 感覺挺有意思，這里簡單記錄下。
在XP時代我們的程序沒有響應后只能通過任務管理器強制殺掉，但是Vista之后情況變了， 我們?nèi)匀豢梢酝蟿邮ロ憫拇翱冢踔量梢試L試最小化和關閉窗口， 我們把這個特性叫住Window Ghosting。
首先我們考慮下怎樣判斷一個窗口是否已經(jīng)失去響應？
一般我們想到的是SendMessageTimeout，給窗口發(fā)送WM_NULL消息，判斷返回是否超時。這當然也是一種方法，但是系統(tǒng)有更方便的API IsHungAppWindow， 該API是判斷窗口是否失去響應的標準方法。我們猜測IsHungAppWindow內(nèi)部是否通過SendMessageTimeout來實現(xiàn)的， 跟蹤下我們會發(fā)現(xiàn)不是我們想象的那樣， IsHungAppWindow內(nèi)部掉用了未公開的API NtUserQueryWindow。
接下來考慮下 IsHungAppWindow 是如何鑒定一個窗口是否在失去響應狀態(tài)？
這是MSDN中的原話：
Determines whether the system considers that a specified application is not responding. An application is considered to be not responding if it is not waiting for input, is not in startup processing, and has not calledPeekMessage within the internal timeout period of 5 seconds.
簡單來說就是程序在非等待輸入狀態(tài) ，不是在程序啟動階段， 并且5秒內(nèi)沒有從消息隊列中取消息。
下面我們思考系統(tǒng)是如何實現(xiàn)Window Ghosting的？
我們知道失去響應的窗口一般來說是因為UI線程正在做一些繁忙的工作， 或是UI線程死鎖而沒有在繼續(xù)運行了。 那這里就很奇怪了， UI線程都失去響應了， 窗口怎么還能響應我們的鼠標拖動消息？我們的鼠標拖動事件需要運行在UI線程中才行 ，該實現(xiàn)有些顛覆我們現(xiàn)有的計算機知識。
這里的關鍵就是我們看到的失去響應的窗口是不是還是我們原來的窗口？ 實際上我們真正的窗口已經(jīng)讓系統(tǒng)用Ghosting窗口替代了。
完整過程是這樣的， 當系統(tǒng)檢測到我們程序窗口失去響應了， 系統(tǒng)進程(dwm.exe)會以相同的Z-order, 位置，大小和Style創(chuàng)建一個ghosting窗口（可以通過SPY查看 ，類名是Ghost）， 我 們看到的失去響應的窗口就是這個窗口， 該窗口的客戶區(qū)內(nèi)容是從老窗口中拷貝過來的。而我們原來真正窗口依舊在那里（style, 位置，大小和z-order都沒有變 )， 但是dwm.exe合成屏幕內(nèi)容是并不會把這個窗口畫出來， 所以我們看起來就是原來的窗口給hide了。
這就是Window Ghosting的奧秘， 我們可以在程序中調(diào)用 API DisableProcessWindowsGhosting 來禁止系統(tǒng)對我們的程序使用 Window Ghosting.
Window Ghosting這個特性很不錯， 讓失去響應的程序也有很好的用戶體驗， 但是它也帶來了一些問題。
我遇到的問題是我們在枚舉窗口的過程中，我們通過GetWindowRect查詢一個失去響應的程序窗口的位置，但是返回結(jié)果卻和我們屏幕上看到的不一致， 因為我們看到的是被我們拖動過的Ghosting window，但是API返回的確是被hide的原窗口的位置。 這種情況下我們需要原窗口和Ghosting窗口的一張映射表， 但是我還沒有找到他們對應關系的方法， 不知道系統(tǒng)又沒有相關API提供？一種方法是通過查找類名是"Ghost"的窗口，判斷進程是不是dwm.exe， 再通過標題匹配。但是該方法效率低，也不可靠。
posted on 2014-01-08 21:26
Richard Wei 閱讀(3258)
評論(3) 編輯 收藏 引用 所屬分類:
windows desktop