有關微軟編程技術的書籍可謂多如牛毛，但讀來讀去感覺還是MSDN比較權威。這里就拿一個例子來說吧，可能讓很多剛開始學習Win32 API程序設計、甚至是一些已經有一定Win32 API經驗的人感覺大汗淋漓。

　　在學習Win32 API程序設計時，“第一課”我想都會學到“事件循環”吧？很多書給出了類似這樣的經典示例：

int WINAPI _tWinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPCTSTR lpCmdLine, int nCmdShow)
{
　MSG msg;
　...
　while(GetMessage(&msg, NULL, 0, 0))
　{
　　TranslateMessage(&msg);
　　DispatchMessage(&msg);
　}
　...
　return (int)msg.wParam;
}

　　沒錯吧？多么熟悉的事件循環，它可以很好地工作，當收到一個WM_QUIT事件的時候，GetMessage()返回0，我們的程序得以正常退出。因此，幾乎任何一本講述Win32 API程序設計的書籍或文章，不論國內的還是國外的，都會以這樣一個程序作為第一章中的示例。

　　然而，就在前不久，和往常一樣，閑來無事就翻起MSDN來，不知怎么的，就跑來看這個再熟悉不過的GetMessage()函數的參考來了。這一看不要緊，頭頂頓時冒出虛汗——原來這么多年我們這么寫程序，不能說是錯誤的，但絕對是有漏洞！來看MSDN上對于GetMessage()函數的講解（節選）：

　　注意：下面一段文字節選自MSDN Library Online，原文參見：

http://msdn.microsoft.com/
library/
en-us/
winui/
winui/
windowsuserinterface/
windowing/
messagesandmessagequeues/
messagesandmessagequeuesreference/
messagesandmessagequeuesfunctions/
getmessage.asp

>Return Value

>If the function retrieves a message other than WM_QUIT, the return value is nonzero.

>If the function retrieves the WM_QUIT message, the return value is zero.

>If there is an error, the return value is -1. For example, the function fails if hWnd is an invalid window handle or lpMsg is an invalid pointer. To get extended error information, call GetLastError.

>Warning
>Because the return value can be nonzero, zero, or -1, avoid code like this:

while (GetMessage( lpMsg, hWnd, 0, 0)) ...

>The possibility of a -1 return value means that such code can lead to fatal application errors. Instead, use code like this:

BOOL bRet;

while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0)
{
　if (bRet == -1)
　{
　　// handle the error and possibly exit
　}
　else
　{
　　TranslateMessage(&msg);
　　DispatchMessage(&msg);
　}
}

　　草譯如下，希望更多的朋友能夠看清：

　　返回值

　　 如果該函數收到一個除WM_QUIT之外的事件，其返回值為一個非零值。

　　 如果該函數收到一個WM_QUIT事件，其返回值為零。

　　 如果該函數發生錯誤，其返回值為-1。例如，如果hWnd是一個無效的窗口句柄，或者lpMsg是一個無效指針，該函數就會失敗。要獲得額外的錯誤信息，請調用GetLastError。

　　警告

　　 由于該函數的返回值可能是非零的、零或者-1，請避免這樣做：

while (GetMessage( lpMsg, hWnd, 0, 0)) ...

　　 返回值-1出現的可能性意味著這樣的代碼會導致應用程序的致命錯誤。因此，我們應該編寫這樣的代碼：

BOOL bRet;

while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0)
{
　if (bRet == -1)
　{
　　// handle the error and possibly exit
　}
　else
　{
　　TranslateMessage(&msg);
　　DispatchMessage(&msg);
　}
}

　　看到了嗎？我們這么長時間以來一直書寫的代碼，卻在這個“警告”中被“明令禁止”了！可能有的朋友會想，這樣的調用不可能出錯啊，我們通常都在啟動事件循環之前成功地創建了窗口，并且檢查了是否成功，因此傳遞給GetMessage()函數的窗口句柄肯定是有效的；而且，我們通常在堆棧上分配msg，并通過求址運算符（&）來計算它的地址并傳遞給GetMessage()函數，也不大可能出現無效指針啊？但是，還記得程序設計的基本原理之一嗎——永遠不要假設任何事情！因此，看來我們該把過去寫的代碼拿出來好好審視一遍了。

　　這里僅提到了一個這樣被我們忽視的技術細節，我想一定還有很多、更多這樣的被忽視的東西存在！希望本文拋磚引玉，大家把你們發現的類似東西分享出來，讓大家都能夠寫出更加安全健壯的程序吧！

　　P.S. 小感受一則，希望不要挨板磚……

　　很多人都罵Windows是如何如何不安全，“緩沖區溢出”甚至變成連小學生都能隨口說出的“名詞”。其實，很多的Windows API都盡量保證了其執行的成功，并且以各種形式反饋給程序員，同時也在文檔中進行了詳細的描述。然而，又有多少人真正好好閱讀了這些講解？有多少技術作者、技術作家在下筆之前認真瀏覽了MSDN Library？

　　Windows是安全的，不安全的是我們想當然的作風！