以訊息為基礎，以事件驅動之（message based， event driven）

Windows 程式的進行系依靠外部發生的事件來驅動。換句話說，程式不斷等待（利用一個while 迴路），等待任何可能的輸入，然後做判斷，然後再做適當的處理。上述的「輸
入」是由作業系統捕捉到之後，以訊息形式（一種資料結構）進入程式之中。作業系統如何捕捉外圍裝置（如鍵盤和滑鼠）所發生的事件呢？噢，USER 模組掌管各個外圍的
驅動程式，它們各有偵測迴路。
如果把應用程式獲得的各種「輸入」分類，可以分為由硬體裝置所產生的訊息（如滑鼠移動或鍵盤被按下），放在系統隊列（system queue）中，以及由Windows 系統或其它
Windows 程式傳送過來的訊息，放在程式隊列（application queue）中。以應用程式的眼光來看，訊息就是訊息，來自哪裡或放在哪裡其實並沒有太大區別，反正程式調用
GetMessage API 就取得一個訊息，程式的生命靠它來推動。所有的GUI 系統，包括UNIX的X Window 以及OS/2 的Presentation Manager，都像這樣，是以訊息為基礎的事件驅動系統。
可想而知，每一個Windows 程式都應該有一個迴路如下：

MSG msg;while (GetMessage(&msg, NULL, NULL, NULL)) {TranslateMessage(&msg);DispatchMessage(&msg);}// 以上出現的函數都是Windows API 函數訊息，也就是上面出現的MSG 結構，其實是Windows 內定的一種資料格式:/* Queued message structure */typedef struct tagMSG{HWND hwnd;UINT message; // WM_xxx，例如WM_MOUSEMOVE，WM_SIZE...WPARAM wParam;LPARAM lParam;DWORD time;POINT pt;} MSG;

接受並處理訊息的主角就是視窗。每一個視窗都應該有一個函數負責處理訊息，程式員必須負責設計這個所謂的「視窗函數」（window procedure，或稱為window function）。如果視窗獲得一個訊息，這個視窗函數必須判斷訊息的類別，決定處理的方式。以上就是Windows 程式設計最重要的觀念。至於視窗的產生與顯示，十分簡單，有專門的API 函數負責。稍後我們就會看到Windows 程式如何把這訊息的取得、指派、處理動作表現出來。