• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            最近工作中遇到Window Ghosting這個問題, 感覺挺有意思,這里簡單記錄下。



            在XP時代我們的程序沒有響應后只能通過任務管理器強制殺掉,但是Vista之后情況變了, 我們仍然可以拖動失去響應的窗口,甚至可以嘗試最小化和關閉窗口, 我們把這個特性叫住Window Ghosting。

            首先我們考慮下怎樣判斷一個窗口是否已經失去響應?
             
            一般我們想到的是SendMessageTimeout,給窗口發送WM_NULL消息,判斷返回是否超時。這當然也是一種方法,但是系統有更方便的API  IsHungAppWindow, 該API是判斷窗口是否失去響應的標準方法。我們猜測IsHungAppWindow內部是否通過SendMessageTimeout來實現的, 跟蹤下我們會發現不是我們想象的那樣, IsHungAppWindow內部掉用了未公開的API NtUserQueryWindow。

            接下來考慮下 IsHungAppWindow 是如何鑒定一個窗口是否在失去響應狀態?

            這是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.
            簡單來說就是程序在非等待輸入狀態 ,不是在程序啟動階段, 并且5秒內沒有從消息隊列中取消息。 

            下面我們思考系統是如何實現Window Ghosting的?

            我們知道失去響應的窗口一般來說是因為UI線程正在做一些繁忙的工作, 或是UI線程死鎖而沒有在繼續運行了。 那這里就很奇怪了, UI線程都失去響應了, 窗口怎么還能響應我們的鼠標拖動消息?我們的鼠標拖動事件需要運行在UI線程中才行 ,該實現有些顛覆我們現有的計算機知識。

            這里的關鍵就是我們看到的失去響應的窗口是不是還是我們原來的窗口? 實際上我們真正的窗口已經讓系統用Ghosting窗口替代了。
            完整過程是這樣的, 當系統檢測到我們程序窗口失去響應了, 系統進程(dwm.exe)會以相同的Z-order, 位置,大小和Style創建一個ghosting窗口(可以通過SPY查看 ,類名是Ghost), 我 們看到的失去響應的窗口就是這個窗口, 該窗口的客戶區內容是從老窗口中拷貝過來的。而我們原來真正窗口依舊在那里(style, 位置,大小和z-order都沒有變 ), 但是dwm.exe合成屏幕內容是并不會把這個窗口畫出來, 所以我們看起來就是原來的窗口給hide了。
             
            這就是Window Ghosting的奧秘, 我們可以在程序中調用 API DisableProcessWindowsGhosting 來禁止系統對我們的程序使用 Window Ghosting.

            Window Ghosting這個特性很不錯, 讓失去響應的程序也有很好的用戶體驗, 但是它也帶來了一些問題。

            我遇到的問題是我們在枚舉窗口的過程中,我們通過GetWindowRect查詢一個失去響應的程序窗口的位置,但是返回結果卻和我們屏幕上看到的不一致, 因為我們看到的是被我們拖動過的Ghosting window,但是API返回的確是被hide的原窗口的位置。 這種情況下我們需要原窗口和Ghosting窗口的一張映射表, 但是我還沒有找到他們對應關系的方法, 不知道系統又沒有相關API提供?一種方法是通過查找類名是"Ghost"的窗口,判斷進程是不是dwm.exe, 再通過標題匹配。但是該方法效率低,也不可靠。
            posted on 2014-01-08 21:26 Richard Wei 閱讀(3231) 評論(3)  編輯 收藏 引用 所屬分類: windows desktop

            FeedBack:
            # re: Window Ghosting
            2014-01-08 21:50 | relax
            挺有意思  回復  更多評論
              
            # re: Window Ghosting[未登錄]
            2014-01-08 22:12 | 萬連文
            記憶中是Send/PostMessage返回FALSE表示窗口假死,Chromium源碼中有的。Ghosting是很早就知道了,感覺有遮罩層的意思,方便接管消息做統一的假死處理。  回復  更多評論
              
            # re: Window Ghosting
            2014-01-09 10:24 | Richard Wei
            @萬連文
            對假死窗口調用SendMessage應該會一直等待,不會返回, 直到窗口有響應  回復  更多評論
              
            一级做a爰片久久毛片毛片| 99久久99久久精品免费看蜜桃| 久久成人精品视频| 精品熟女少妇aⅴ免费久久| 精品多毛少妇人妻AV免费久久| 久久综合色区| 狠狠色婷婷久久一区二区三区| 精品久久久久久国产免费了| 免费精品久久天干天干| 久久亚洲精精品中文字幕| 久久久久久国产精品美女| 亚洲国产精品无码久久一区二区 | 久久精品不卡| 久久亚洲中文字幕精品有坂深雪 | 亚洲欧美精品伊人久久| 伊人久久成人成综合网222| 久久久久久狠狠丁香| 久久国产色av免费看| 久久久久亚洲AV综合波多野结衣 | 亚洲国产成人久久精品99| 国产精品18久久久久久vr| 久久天天躁夜夜躁狠狠| 久久国产精品免费一区二区三区| 伊人久久大香线蕉综合热线| 亚洲欧美精品伊人久久| 国产精品一区二区久久不卡| 久久精品国产精品亚洲精品| 性做久久久久久免费观看| 国产巨作麻豆欧美亚洲综合久久| 麻豆AV一区二区三区久久 | 久久综合亚洲色HEZYO国产| 色偷偷888欧美精品久久久| 97久久精品人妻人人搡人人玩| 色综合久久综合中文综合网| 久久久久亚洲av成人网人人软件 | 国产免费久久精品99re丫y| 精品免费久久久久国产一区 | 青草影院天堂男人久久| 久久精品国产一区二区三区日韩| 99久久久精品| 99久久国产主播综合精品|