@陳利敏
可以用先用API Monitor 或者WinDbg的API斷點看看對方程序是如何工作的

這里有意思的地方在于面對著一個com對象，你居然沒有辦法知道到它究竟實現了多少接口。微軟自己也也意識到了這個問題， 于是WinRT里就有了IInspectable::GetIids， https://msdn.microsoft.com/en-us/library/br205822(v=vs.85).aspx

歡迎回來...

@josanna
不行就開線程吧，還不行可以嘗試提高線程的優先級

@游戲狗…
這個需要DUILib庫的開發為每個控件實現IAccessible接口，自動測試再通過這個接口查詢和操作控件, 思路就那樣，手頭現成的Demo也我沒有.

@謝應彪
要點我在這篇文章里都說了 http://m.shnenglu.com/weiym/archive/2014/11/15/208885.html

我們的Windows Client就是基于開源的DUILib的， 有興趣可以試用下 zoom.us

@春秋十二月
是的，計算機技術的變化可以說很快，也可以說很慢?？斓姆矫鎭碚f，各種新語言新技術新平臺層出不窮，好像三天兩頭在變；慢的方面來說，數據結構和算法，語言范型，網絡協議，馮諾依曼體系結構等幾十年來都很穩定，練好內功才能以靜制動。

@longjoy
按我上面說的做就可以了支持了，公司內部代碼，外面應該下載不到...

@test
看來確實是歷史原因， 不過對于運行期的程序來說，個人倒是更贊同Windows的做法，忽略內存因素，Windows的UCS2編碼相對于其他平臺的UTF8更統一和高效。

@lchen
這個沒啥好方法， 感覺只能通過查看每個堆建立時的堆棧情況來判斷

試了下， 貌似就是這樣的。實在不行就不要Destroy B了， 用Hide B替代吧

@春秋十二月
理解, 基礎庫大量用模板我也沒反對...

哈哈， 我現在也比較趨向簡單的設計， 有時間玩模板的奇淫技巧， 還不如花時間解決幾個實際的問題。
曾經思考過C++的編程風格： http://m.shnenglu.com/weiym/archive/2013/04/27/199781.html

@bukebushuo
不知道老弟的界面庫賣的怎么樣了。

DUI支持讀屏我已經做了， 就按我上面說的方法。
實際上QQ的界面庫也是支持讀屏的，有興趣的話可以在win7/win8上嘗試 “控制面板\輕松使用\輕松使用設置中心\啟動講訴人”, 然后在QQ上通過Tab切換控件焦點。

@duanyuncanyang
memory pool 本身只負責內存分配，是給對象的operate new 和operate delete調用的，具體參見上面的測試代碼

@cc
本來就是, C++異常只能捕獲軟件異常， 硬件異常(如除零，空指針訪問)用操作系統的SEH捕獲。

完整版： http://windbg.info/doc/1-common-cmds.html

有人提到中文中夾雜英文的問題，不多說了，在外企呆過的同學應該都會不自覺地有這個習慣，并且有時候錯誤的中文還不如用原始的英文。

@allen
剛才有簡單測試了下， 測試代碼如下：
D3DPRESENT_PARAMETERS ps = {0};
ps.Windowed = TRUE;
ps.SwapEffect = D3DSWAPEFFECT_DISCARD;
ps.BackBufferFormat = D3DFMT_UNKNOWN;

pD3D->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL
, hWnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, &ps, &g_pD3dDevice);
if(g_pD3dDevice == NULL) break;


LPDIRECT3DDEVICE9 pNewD3dDevice = NULL;
pD3D->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL
, hWnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, &ps, &pNewD3dDevice);

創建了2個IDirect3DDevice9對象， 然后分別打印它們的虛表指針和內容：

0:000> ?? g_pD3dDevice
struct IDirect3DDevice9 * 0x02815c00
+0x000 __VFN_table : 0x0281899c
0:000> ?? pNewD3dDevice
struct IDirect3DDevice9 * 0x0241bfe0
+0x000 __VFN_table : 0x0241ed7c
0:000> dps 0x0281899c
0281899c 6fe56f19 d3d9!CBaseDevice::QueryInterface
028189a0 6fe56992 d3d9!CBaseDevice::AddRef
028189a4 6fe56969 d3d9!CBaseDevice::Release
028189a8 6fe72587 d3d9!CBaseDevice::TestCooperativeLevel
028189ac 6ff0c6ad d3d9!CBaseDevice::GetAvailableTextureMem
028189b0 6ff49c8f d3d9!CD3DBase::EvictManagedResources
028189b4 6fe6b1c5 d3d9!CBaseDevice::GetDirect3D
028189b8 6fe56ff8 d3d9!CBaseDevice::GetDeviceCaps
028189bc 6fe8d144 d3d9!CBaseDevice::GetDisplayMode
028189c0 6fe7084e d3d9!CBaseDevice::GetCreationParameters
028189c4 6ff0bb74 d3d9!CBaseDevice::SetCursorProperties
028189c8 6ff0c04d d3d9!CBaseDevice::SetCursorPosition
028189cc 6fe8def0 d3d9!CBaseDevice::ShowCursor
028189d0 6fe6e9a0 d3d9!CBaseDevice::CreateAdditionalSwapChain
028189d4 6fe69ac7 d3d9!CBaseDevice::GetSwapChain
028189d8 6fe993ca d3d9!CBaseDevice::GetNumberOfSwapChains
028189dc 6feaf251 d3d9!CBaseDevice::Reset
028189e0 6fe9a064 d3d9!CBaseDevice::Present
028189e4 6feb1418 d3d9!CBaseDevice::GetBackBuffer
028189e8 6fe6bfe9 d3d9!CBaseDevice::GetRasterStatus
028189ec 6ff0c139 d3d9!CBaseDevice::SetDialogBoxMode
028189f0 6ff0c3bf d3d9!CBaseDevice::SetGammaRamp
028189f4 6ff0c4fd d3d9!CBaseDevice::GetGammaRamp
028189f8 6fe85ddb d3d9!CBaseDevice::CreateTexture
028189fc 6ff0ca68 d3d9!CBaseDevice::CreateVolumeTexture
02818a00 6feacb2d d3d9!CBaseDevice::CreateCubeTexture
02818a04 6fe72d69 d3d9!CBaseDevice::CreateVertexBuffer
02818a08 6fe732e6 d3d9!CBaseDevice::CreateIndexBuffer
02818a0c 6fea0127 d3d9!CBaseDevice::CreateRenderTarget
02818a10 6ff0cd88 d3d9!CBaseDevice::CreateDepthStencilSurface
02818a14 6ff0e0e0 d3d9!CBaseDevice::UpdateSurface
02818a18 6fe846ab d3d9!CBaseDevice::UpdateTexture
0:000> dps 0x0241ed7c
0241ed7c 6fe56f19 d3d9!CBaseDevice::QueryInterface
0241ed80 6fe56992 d3d9!CBaseDevice::AddRef
0241ed84 6fe56969 d3d9!CBaseDevice::Release
0241ed88 6fe72587 d3d9!CBaseDevice::TestCooperativeLevel
0241ed8c 6ff0c6ad d3d9!CBaseDevice::GetAvailableTextureMem
0241ed90 6ff49c8f d3d9!CD3DBase::EvictManagedResources
0241ed94 6fe6b1c5 d3d9!CBaseDevice::GetDirect3D
0241ed98 6fe56ff8 d3d9!CBaseDevice::GetDeviceCaps
0241ed9c 6fe8d144 d3d9!CBaseDevice::GetDisplayMode
0241eda0 6fe7084e d3d9!CBaseDevice::GetCreationParameters
0241eda4 6ff0bb74 d3d9!CBaseDevice::SetCursorProperties
0241eda8 6ff0c04d d3d9!CBaseDevice::SetCursorPosition
0241edac 6fe8def0 d3d9!CBaseDevice::ShowCursor
0241edb0 6fe6e9a0 d3d9!CBaseDevice::CreateAdditionalSwapChain
0241edb4 6fe69ac7 d3d9!CBaseDevice::GetSwapChain
0241edb8 6fe993ca d3d9!CBaseDevice::GetNumberOfSwapChains
0241edbc 6feaf251 d3d9!CBaseDevice::Reset
0241edc0 6fe9a064 d3d9!CBaseDevice::Present
0241edc4 6feb1418 d3d9!CBaseDevice::GetBackBuffer
0241edc8 6fe6bfe9 d3d9!CBaseDevice::GetRasterStatus
0241edcc 6ff0c139 d3d9!CBaseDevice::SetDialogBoxMode
0241edd0 6ff0c3bf d3d9!CBaseDevice::SetGammaRamp
0241edd4 6ff0c4fd d3d9!CBaseDevice::GetGammaRamp
0241edd8 6fe85ddb d3d9!CBaseDevice::CreateTexture
0241eddc 6ff0ca68 d3d9!CBaseDevice::CreateVolumeTexture
0241ede0 6feacb2d d3d9!CBaseDevice::CreateCubeTexture
0241ede4 6fe72d69 d3d9!CBaseDevice::CreateVertexBuffer
0241ede8 6fe732e6 d3d9!CBaseDevice::CreateIndexBuffer
0241edec 6fea0127 d3d9!CBaseDevice::CreateRenderTarget
0241edf0 6ff0cd88 d3d9!CBaseDevice::CreateDepthStencilSurface
0241edf4 6ff0e0e0 d3d9!CBaseDevice::UpdateSurface
0241edf8 6fe846ab d3d9!CBaseDevice::UpdateTexture

可以看到g_pD3dDevice的虛表地址是0x0281899c, pNewD3dDevice的虛表地址是0x0241ed7c，他們各自擁有自己虛表，盡管虛表里的內容是一樣。如果你改變第一個對象的虛表內容，理論上不會影響第二個對象。

@WXX
慚愧，真心熱愛計算機的大學畢業時就很厲害了， 昨天看到的 http://www.zhihu.com/question/23241706/answer/24087891

我是大學沒努力，工作后根據需要補學而已。

@Won
確實，DWM虛擬化只有在大于125%時才會自動開啟

@allen
BitBlt主要針對Monitor DC， 抓某個Monitor的屏幕內容
WindowDC可以抓任何一個窗口的內容， 當然抓時也要BitBlt

@jenics
是不是因為你的程序是沒有PDB文件的Release版

@allen
嗯, 單看這句話確實是錯的， 但是你要結合我的上下文來看。
我的意思是你這里修改IDirect3DDevice9的虛表內容， 修改的也僅是你當前對象的， 而不會影響其他IDirect3DDevice9對象， 因為他們不是所有對象共享同一虛表的， 但是同一標準C++類的所有對象會共享同一虛表。

@萬連文
對假死窗口調用SendMessage應該會一直等待,不會返回, 直到窗口有響應

@Q
多謝指正， 因為具體我也沒試過， 只是看微軟文檔得出的結論，可看這里第一句：http://msdn.microsoft.com/en-us/library/windows/desktop/hh404487(v=vs.85).aspx

@萬連文
RDP協議是不公開的，他主要定義了圖像的壓縮，加密，傳輸和遠程控制等方法， 本身沒有定義屏幕采樣方法，微軟的遠程桌面用的應該是mirror driver的抓屏。

effective C++ item 38

@萬連文
嗯，確實度是關鍵， 實際上怎樣才算一個模塊？ 它的粒度可以是個小的靜態Library， 也可能是個龐大的Service。最關鍵的就是要保持模塊的獨立性和層次性，避免形成網狀依賴。

@春秋十二月
同意,相對Unix/Linux的穩定， Windows開發要累得多

@StarsunYzL
已經加上, 如有不正確的地方,歡迎指正.

@flighta
如果別人已經保存了你這個DLL的HINSTANCE，你想熱替換它，這個恐怕不好弄， 只能讓別人Free后再Load。

@唐地坤
關鍵就是參數CAPTUREBLT， 它讓BitBlt把Layered Window抓下來

@唐地坤
不是很明白你的問題,不知道你是不是指這個BitBlt( ... SRCCPY | CAPTUREBLT)

小心點擊超500

@聶晏冰

怎么取一次？
每次收到消息都要轉的， 大概代碼如下：
LRESULT CALLBACK XWindow::WndProc(HWND hWnd, UINT uMsg,
WPARAM wParam, LPARAM lParam)
{
XWindow* pThis = NULL;
if (WM_NCCREATE == uMsg)
{
assert(!::IsBadReadPtr((void*)lParam, sizeof(CREATESTRUCT)));
LPCREATESTRUCT lpcs = reinterpret_cast(lParam);
pThis = static_cast(lpcs->lpCreateParams);
pThis->m_hWnd = hWnd;

assert(!::IsBadReadPtr(pThis, sizeof(XWindow)));
::SetWindowLongPtr(hWnd, GWLP_USERDATA, reinterpret_cast(pThis));
}
else
pThis = reinterpret_cast(::GetWindowLongPtr(hWnd, GWLP_USERDATA));

if (pThis)
return pThis->MsgProc(hWnd, uMsg, wParam, lParam);
else
return DefWindowProc(hWnd, uMsg, wParam, lParam);
}

@jilei
不錯, UserData方式也可以用SetProp存儲， 但是低效同樣也是它的缺點。

@avlee
嗯，關鍵我們希望是面向對象的， 方便的支持多實例， 并且希望是線程安全的，這個框架都很好的滿足了。消息處理是窗口程序的根本， 所以簡單方便的消息映射也很重要。

記錄下, 對于菜單窗口, 可以優化消息WM_MOUSEACTIVATE, 返回MA_NOACTIVATE

@bukebushuo
不敢，最近工作中用到這塊東西，所以花點時間總結了下，順便分享

@笨笨熊
基本不可能, 這個用戶體驗也太差了吧

@foundwant
確實， 這和分配策略有關。
上面的內存池適合頻繁的分配和釋放的情況， 但是對于多次連續分配就不適合了。其他一些內存池可參考：http://m.shnenglu.com/weiym/archive/2013/04/08/199238.html

@艾絲凡
恩，文章主要針對C++開發人員的， 沒有這方面經驗是比較難看懂。

@WXX
同意， 關于套間、列集/散集， 內部涉及到LPC/RPC技術，微軟隱藏了太多東西，盡管Windows操作系統本身用了不少這方面的技術， 但是外部開發人員卻因為不好掌控而盡量不用。

@bukebushuo
確實， 關于Windows桌面應用的下降趨勢， 我以前有過一篇文章http://m.shnenglu.com/weiym/archive/2012/06/21/179645.html

@cao
慚愧，不敢誤人子弟。

還很年輕，加油

這不是偶的文章嗎，被斬頭去尾了...

rpc

說的不錯。其實什么線程都一樣， 這里多了個消息隊列和消息循環，就被叫為 “UI線程”。