Win32匯編--圖形操作--GDI原理
Windows是基于圖形界面的，所以在Win32編程中，圖形操作是最常用的操作。GDI的意義在于將程序對圖形界面的操作和硬件設備隔絕開來，在程序中可以將所有的圖形設備都看成是虛擬設備，包括視頻顯示器和打印機等，然后通過GDI函數用同樣的方法去操作它們，由Windows負責將函數調用轉化成針對具體硬件的操作。只要一個設備提供了和Windows兼容的驅動程序，它就可以被看做是一個標準的設備。以前在DOS系統下寫應用程序的時候，如果要進行圖形操作，那么就要考慮到市場上每種顯示卡的不同，否則在裝配某種顯卡的計算機上就可能無法正常運行，對匯編程序員來說，這真是一個惡夢。在Win32編程中，正是GDI函數讓這個惡夢成為歷史。
GDI函數全部包括在GDI32.DLL中，在編程的時候，注意要在源程序的開頭加上相應的包含語句：
include gdi32.inc
includelib gdi32.lib
和GDI相關的內容真是太龐大了，只要查看一下gdi32.inc文件就可以發現，函數的總數達到了300多個，和GDI相關的數據結構也非常多，為了能了解GDI的原理和基本的使用方法：
歸納起來，GDI操作可以從3個方面去了解——When, Where和How：
When——指的是進行圖形操作的時機，究竟什么時刻最適合程序進行圖形操作呢？——“GDI程序的結構”
Where——指的是圖形該往哪里畫，既然Windows隔離了硬件圖形設備，那么該把什么地方當做“下筆”的地方呢？——“設備環境”
How——了解了上面兩個問題后，最后還要知道“如何畫”，這就涉及如何使用大部分GDI函數的問題了。
一、GDI程序的結構
1、客戶區的刷新
正如上面所說的，這里討論的是“When”的問題，讀者可能會問：為什么會有這個問題，如果要向窗口輸出圖形，程序想在什么時候輸出那就是什么時候，難道這個時刻還有規定不成？
在DOS操作系統中編程的時候，程序把文字或圖形輸出到屏幕，在輸出新的內容之前，這些內容總是保留在屏幕原處，這些內容會被意外覆蓋的唯一情況是激活一個TSR程序，但TSR程序在退出之前有義務恢復原來的屏幕，如果它無法恢復屏幕的內容，那么這是它的責任，我們不會在自己的程序中去考慮屏幕內容會無緣無故消失這種情況，所以可以把屏幕看成是應用程序私有的。
如果程序輸出的內容過多，如用dir顯示一個含有很多文件的目錄，用戶根本無法看清快速上翻的屏幕，這時程序可以設計一個參數來暫停一下，如dir/p。這已經是DOS程序最“體貼”的做法了，如果用戶想回過頭去看已經滾出屏幕的內容，那可對不起，只能再執行一遍了！
所以對DOS程序來說，程序想在什么時候輸出信息那就是什么時候，根本不存在When這個問題。
但在Windows操作系統中，屏幕是多個程序“公用”的，用戶程序不要指望輸出到窗口中的內容經過一段時間后還會保留在那里，它們可能被別的東西覆蓋，如其他窗口、鼠標箭頭或下拉的菜單等。在Windows中，恢復被覆蓋內容的責任大部分屬于用戶程序自己，理由很簡單：Windows是個多任務的操作系統，假如程序B覆蓋了程序A的窗口內容，覆蓋掉的內容由程序B負責恢復的話，它就必須保存它覆蓋掉的內容，但是在它將保存的內容恢復之前，程序A也在運行，并可能在程序B恢復以前已經向它自己的窗口輸出新的內容，結果當程序B恢復它保存的窗口內容時，保存的內容可能是過時的（而DOS的情況就不同，TSR程序激活的時候，用戶程序是被掛起的），所以最好的辦法就是讓程序A自己來決定如何恢復。
Windows系統采用的方法是：當Windows檢測到窗口被覆蓋的地方需要恢復的時候，它會向用戶程序發送一個WM_PAINT消息，消息中包括了需要恢復的區域，然后由用戶程序來決定如何恢復被覆蓋的內容。
如果程序因為忙于處理其他事務以至于無法及時響應WM_PAINT消息，那么窗口客戶區原先被覆蓋的地方可能會被Windows暫時畫成一塊白色（或者背景色）的矩形，或者根本就是保留被覆蓋時的情形，直到程序有時間去響應WM_PAINT消息為止。我們常常可以看到這種情況發生在死鎖程序的客戶區內，這就是因為死鎖的程序無法響應WM_PAINT消息來恢復客戶區造成的。
所以對于“When”這個問題，答案是：程序應該在Windows要求的時候繪畫客戶區，也就是在收到WM_PAINT消息的時候。如果程序需要主動刷新客戶區，那么可以通過調用InvalidateRect等函數引發一條WM_PAINT消息，因為在WM_PAINT消息中刷新客戶區的代碼是必須存在的，所以用這種看似“舍近求遠”的辦法實際上可以節省一份重復的代碼。即使是在游戲程序這種“主動刷新”遠遠多于“被動刷新”的程序中，只要窗口有被其他東西覆蓋的可能，那么這個原則就是適用的。
2、GDI程序的結構
對于Win32程序來說，WM_PAINT消息隨時可能發生，這就意味著，程序再也不能像在DOS下一樣輸出結果后就不管了，反過來，程序在任何時刻都應該知道如何恢復整個或局部客戶區中以前輸出的內容。
如果程序的功能比較簡單，可以將計算及刷新整個客戶區的代碼全部安排在WM_PAINT消息中完成，這樣，每次當客戶區的全部或部分需要被更新的時候，程序重新執行整個生成客戶區屏幕數據的功能模塊并刷新客戶區。這種結構適用于功能模塊很短小且執行速度很快的情況，整個過程的時間最好不超過幾百ms，否則，用戶會在一個明顯的等待時間后才看到程序把客戶區中的“空洞”補上。
當生成屏幕數據的功能模塊有些復雜的時候，就應該考慮采用如下結構，即功能模塊和客戶區刷新模塊分別在不同的子程序中實現，功能模塊單獨用一個子程序完成，這個子程序可以由用戶通過選擇菜單項在WM_COMMAND消息中執行，也可以新建另外一個線和來完成，總之，它最后把計算結果放到一個緩沖區中，而每當客戶區需要刷新時，程序在WM_PAINT消息中調用客戶區刷新子程序，這個子程序從計算好的緩沖區中取出數據并輸出到客戶區中，由于單純的屏幕刷新過程是很快的，所以用戶根本來不及看到客戶區中的空洞。
3、探討WM_PAINT消息
當客戶區被覆蓋并重新顯示的時候，Windows并不是在所有的的下都發送WM_PAINT消息，下面是幾種不同的情況：
l 當鼠標光標移過窗口客戶區以及圖標拖過客戶區這兩種情況，Windows總是自己保存被覆蓋的區域并恢復它，并不需要發送WM_PAINT消息通知用戶程序。
l 當窗口客戶區被自己的下拉式菜單覆蓋，或者被自己彈出的對話框覆蓋后，Windows會嘗試保存被覆蓋的區域并在以后恢復它，如果因為某種原因無法保存并恢復的話，Windows會發送一個WM_PAINT消息通知程序。
l 別的情況造成窗口的一部分從不可見變到可見，如程序從最小化的狀態恢復，其他的窗口覆蓋客戶區后移開，用戶改變了窗口的大小不一和用戶按動滾動條等，在這些情況下，Windows會向窗口發送WM_PAINT消息。
l 一些函數會引發WM_PAINT消息，如UpdateWindow，InvalidateRect以及InvalidateRgn函數等。
窗口過程收到WM_PAINT消息后，并不代表整個客戶區都需要被刷新，有可能客戶區被覆蓋的區域只有一小塊，這個區域就叫做“無效區域”，程序只需要更新這個區域。
和WM_TIMER消息類似，WM_PAINT消息也是一個低級別的消息，雖然它不會像WM_TIMER消息一樣被丟棄，但Windows總是在消息循環空的時候才把WM_PAINT放入其中，實際上，Windows為每個窗口維護一個“繪圖信息結構”，無效區域的坐標就在其中，每當消息循環空的時候，如果Windows發現存在一個無效區域，就會放入一個WM_PAINT消息。
無效區域的坐標并不附帶在WM_PAINT消息的參數中，在程序中有其他方法可以獲取，WM_PAINT消息只是通知程序有個區域需要更新而已，所以Windows也不會同時將兩條WM_PAINT消息放入消息循環，當Windows要放入一條WM_PAINT消息的時候，如果發現已存在一個無效區域了，那么它只需要把新舊兩個無效區域合并計算出一個新的無效區域就可以了，消息循環中還是只需要一條WM_PAINT消息。
由于存在“無效區域”這樣一個東西，所以程序在WM_PAINT消息中對客戶區刷新完畢后工作并沒有結束，如果不使無效區域變得有效，Windows會在下一輪消息循環中繼續放入一個WM_PAINT消息。當Windows檢查“繪圖信息結構”的時候發現沒有了無效區域，也就不會繼續發送WM_PAINT消息了。
WM_PAINT消息的處理流程一般是：
.if eax == WM_PAINT ;eax為uMsg
invoke BeginPaint, hWnd, addr stPS
;刷新客戶區的代碼
invoke EndPaint, hWnd, addr stPS
xor eax, eax
ret
讀者可以發現中間并沒有調用ValidateRect來使無效區域變得有效，這是因為BeginPaint函數和EndPaint函數隱含有這個功能，如果不是以BeginPaint/EndPaint當做消息處理代碼的頭尾的話，那么在WM_PAINT消息返回的時候就必須調用ValidateRect函數。
BeginPaint函數的第二個參數是一個繪圖信息結構的緩沖區地址，Windows會在這里返回繪圖信息結構，結構中包含了無效區域的位置和大小，繪圖信息結構的定義如下：
PAINTSTRUCT STRUCT
hdc DWORD ?
fErase DWORD ?
rcPaint RECT <>
fRestore DWORD ?
fIncUpdate DWORD ?
rgbReserved BYTE 32 dup(?)
PAINTSTRUCT ENDS
其中hdc字段是窗口的設備環境句柄，rcPaint字段是一個RECT結構，它指定了無效區域矩形的對角頂點，fErase字段如果為非零值，表示Windows在發送WM_PAINT消息前已經用背景色擦除了無效區域，后面3個字段是Windows內部使用的，應用程序不必去理會它們。
二、設備環境
解決了“When”的總是后，再考慮一下“Where”的問題。
在DOS操作系統中，向屏幕輸出數據實際上是把輸出內容拷貝到視頻緩沖區中，如果在文本模式下顯示信息，只需要把內容拷貝到B8000h處的內存中；顯示圖形信息，可以把圖形數據拷貝到A0000h處的內存中。
在Windows中，GDI接口把程序和硬件分隔出來，在Win32編程中，再也不能通過直接向視頻緩沖區拷貝數據的辦法來顯示信息了，那么，究竟該往哪里輸出圖形呢——這就是“Where”的問題。答案是：通過“設備環境”來輸出圖形。
1、什么是設備環境
在Windows中，所有與圖形相關的操作都是用統一的方法來完成的（不然就不能稱為“圖形設備接口”了）。不管是繪畫屏幕上的一個窗口，還是把圖形輸出到打印機，或者對一幅位圖進行繪畫，使用的繪圖函數都是相同的，為了實現方法上的統一，必須將所有的圖形對象看成是一個虛擬的設備，這些設備可能有不同的屬性，如黑白打印機和彩色屏幕的顏色深度是不同的，不同打印機的尺寸和分辨率可能是不同的，繪圖儀只支持矢量而不支持位圖等。不同設備的不同屬性就構成了一個繪圖的“環境”，就像DOS操作系統中把視頻緩沖區當做圖形操作的對象一樣，這個繪圖的“環境”就是Win32編程中圖形操作的對象，把它叫做“設備環境”。設備環境實際上是一個數據結構，結構中保存的就是設備的屬性，當對設備環境進行圖形操作的時候，Windows可以根據這些屬性找到對應的設備進行相關的操作。
在實際使用中，通過“設備環境”可以操作的對象很廣泛，除了可以是打印機或繪圖儀等硬件設備外，也可以是窗口的客戶區，包括大大小小的所有可以被稱為窗口的按鈕與控件等的客戶區，也可以是一個位圖。總之，任何需要用到圖形操作的東西都可以通過“設備環境”進行繪圖。
為了更好地理解“設備環境”是什么，先來看一個例子：
//DcCopy.asm
.386
.model flat, stdcall
option casemap:none
;>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
; Include 文件定義
;>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
include windows.inc
include gdi32.inc
includelib gdi32.lib
include user32.inc
includelib user32.lib
include kernel32.inc
includelib kernel32.lib
;>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
ID_TIMER equ 1
;>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
; 數據段
;>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
.data?
hInstance dd ?
hWin1 dd ?
hWin2 dd ?
.const
szClass1 db 'SourceWindow',0
szClass2 db 'DestWindow',0
szCaption1 db '請嘗試用別的窗口覆蓋本窗口!',0
szCaption2 db '本窗口圖像拷貝自另一窗口',0
szText db 'Win32 Assembly, Simple and powerful!',0
;>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
.code
;>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
; 定時器過程
;>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
_ProcTimer proc _hWnd, uMsg, _idEvent, _dwTime
local @hDc1, @hDc2
local @stRect:RECT
invoke GetDC, hWin1
mov @hDc1, eax
invoke GetDC, hWin2
mov @hDc2,eax
invoke GetClientRect, hWin1, addr @stRect
invoke BitBlt, @hDc2, 0, 0, @stRect.right, @stRect.bottom, @hDc1, 0, 0, SRCCOPY
invoke ReleaseDC, hWin1, @hDc1
invoke ReleaseDC, hWin2, @hDc2
ret
_ProcTimer endp
;>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
; 窗口過程
;>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
_ProcWinMain proc uses ebx edi esi, hWnd, uMsg, wParam, lParam
local @stPs:PAINTSTRUCT
local @stRect:RECT
local @hDc
mov eax, uMsg
mov ecx, hWnd
;****************************************************************
.if eax == WM_PAINT && ecx == hWin1
invoke BeginPaint, hWnd, addr @stPs
mov @hDc, eax
invoke GetClientRect, hWnd, addr @stRect
invoke DrawText, @hDc, addr szText, -1, addr @stRect, DT_SINGLELINE or DT_CENTER or DT_VCENTER
invoke EndPaint, hWnd, addr @stPs
;****************************************************************
.elseif eax == WM_CLOSE
invoke PostQuitMessage, NULL
invoke DestroyWindow, hWin1
invoke DestroyWindow, hWin2
;****************************************************************
.else
invoke DefWindowProc, hWnd, uMsg, wParam, lParam
ret
.endif
;****************************************************************
xor eax, eax
ret
_ProcWinMain endp
;>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
_WinMain proc
local @stWndClass:WNDCLASSEX
local @stMsg:MSG
local @hTimer
invoke GetModuleHandle, NULL
mov hInstance, eax
invoke RtlZeroMemory, addr @stWndClass, sizeof @stWndClass
;****************************************************************
invoke LoadCursor, 0, IDC_ARROW
mov @stWndClass.hCursor, eax
push hInstance
pop @stWndClass.hInstance
mov @stWndClass.cbSize, sizeof WNDCLASSEX
mov @stWndClass.style, CS_HREDRAW or CS_VREDRAW
mov @stWndClass.lpfnWndProc, offset _ProcWinMain
mov @stWndClass.hbrBackground, COLOR_WINDOW + 1
mov @stWndClass.lpszClassName, offset szClass1
invoke RegisterClassEx, addr @stWndClass
invoke CreateWindowEx, WS_EX_CLIENTEDGE, offset szClass1, offset szCaption1, WS_OVERLAPPEDWINDOW, 450, 100, 300, 300, NULL, NULL, hInstance, NULL
mov hWin1, eax
invoke ShowWindow, hWin1, SW_SHOWNORMAL
invoke UpdateWindow, hWin1
;****************************************************************
mov @stWndClass.lpszClassName, offset szClass2
invoke RegisterClassEx, addr @stWndClass
invoke CreateWindowEx, WS_EX_CLIENTEDGE, offset szClass2, offset szCaption2, WS_OVERLAPPEDWINDOW, 100, 100, 300, 300, NULL, NULL, hInstance, NULL
mov hWin2, eax
invoke ShowWindow, hWin2, SW_SHOWNORMAL
invoke UpdateWindow, hWin2
;****************************************************************
; 設置定時器
;****************************************************************
invoke SetTimer, NULL, NULL, 100, addr _ProcTimer
mov @hTimer, eax
;****************************************************************
; 消息循環
;****************************************************************
.while TRUE
invoke GetMessage, addr @stMsg, NULL, 0, 0
.break .if eax == 0
invoke TranslateMessage, addr @stMsg
invoke DispatchMessage, addr @stMsg
.endw
;****************************************************************
; 清除定時器
;****************************************************************
invoke KillTimer, NULL, @hTimer
ret
_WinMain endp
;>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
start:
call _WinMain
invoke ExitProcess, NULL
;>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
end start
這個程序的代碼用到的大部分知識都是前面已經講到的，在_WinMain中，用一個同樣的窗口類建立了兩個窗口，兩個窗口屬于同一個窗口類，所以它們的窗口過程都是_ProcWinMain，為了關閉任何一個窗口都可以結束程序，WM_CLOSE消息中用DestroyWindow函數摧毀了兩個窗口。程序設置了一個周期為100ms的定時器，Windows會每隔100ms調用_ProcTimer子程序。在_ProcTimer中，將其中一個窗口的客戶區拷貝到另一個窗口的客戶區中，方法是通過GetDC獲取窗口的DC句柄，并用BitBlt函數完成拷貝工作，所以在右邊的窗口顯示了一句“Win32 Assembly, Simple and powerful!”，左邊的窗口中也會出現這句話。
程序每100ms將右邊窗口的客戶區拷貝到左邊的窗口客戶區中，通過左邊窗口的客戶區就可以了解右邊客戶區的DC對應的究竟是什么內容。
通過左邊窗口的變化可以驚奇地發現：右邊窗口客戶區的內容并不是程序自己輸出到客戶區的那句文本，而是以客戶區為矩形區域的屏幕上我們真正看到的東西，它竟然包括其他窗口覆蓋在上面的東西。這就意味著，掃雷游戲和紙牌游戲通過自己客戶區對應的設備環境畫圖形，圖形數據竟然畫到了DcCopy窗口客戶區對應的設備環境中。
這個例子驗證了“設備環境”只是“環境”而不是“設備”，它并不存儲發給它的圖形數據，圖形數據透過它寫到了它所描述的“設備”上，每個窗口客戶區的“設備環境”對應的設備都是屏幕，但它們在位置上可能重疊，所以向一個窗口的客戶區寫數據相當于同時寫了下層窗口的客戶區。
為了讓當前激活的窗口在視覺上保持在最上面，下層窗口向自己客戶區寫的內容首先要經過Windows的“過濾”，只有沒有被其他窗口覆蓋掉的部分才真正被寫到了屏幕上。
讀者應該時刻提醒自己——“設備環境”只是一個環境，是設備屬性的一組定義，程序輸出的圖形數據透過“設備環境”被定向到了具體的設備上，“設備環境”本身并不存儲這些數據。
Device Context中Context的含義：設備環境的上面是應用程序，下面是具體設備，而它是用來“聯系上下關系”用的。
有人可能認為：屏幕上的窗口就像放在桌面上的一張張紙，雖然一張紙可能暫時被另一張遮住，但紙上寫的東西還是存在的，移開另一張紙就可以再次露出來。但實際情況是：桌面更像一個用粉筆寫的公告黑板，一個窗口相當于劃了一塊空間寫告示，寫另一個告示的時候要把老告示的內容擦去一部分以便寫新的內容，擦去的東西也就不存在了，如果要恢復老告示，那么必須把擦去的部分重新寫上去。
2、獲取設備環境句柄
要想對任何設備繪圖，首先必須獲取設備的“設備環境句柄”（hDC），幾乎所有的GDI函數的操作目標都是hDC，在程序中得到一個hDC有幾種方法。
最常用的方法是在WM_PAINT消息中用BeginPaint函數得到hDC，WM_PAINT消息的代碼結構一般是：
.if eax == WM_PAINT ;eax為uMsg
invoke BeginPaint, hWnd, addr stPS
;刷新客戶區的代碼
invoke EndPaint, hWnd, addr stPS
xor eax, eax
ret
BeginPaint函數的返回值就是需要刷新區域的hDC。要注意的是：BeginPaint返回的hDC對應的尺寸僅是無效區域，無法用它繪畫到這個區域以外的地方去。由于窗口過程每次接收WM_PAINT消息時的無效區域可能是不同的，所以這個hDC的值僅在WM_PAINT消息中有效，程序不應該保存它并把它用在WM_PAINT消息以外的代碼中。基于同樣的道理，BeginPaint和EndPaint函數只能用在WM_PAINT消息中，因為只有這時候才存在無效區域。
程序中常常有這種需求，就是在非WM_PAINT消息中主動繪畫客戶區，由于BeginPaint和EndPaint函數必須在WM_PAINT消息中使用，所以這時必須用另外的方法獲取hDC，可以使用以下的方法：
invoke GetDC, hWnd ;獲取hDC
;返回值是hDC
;繪圖代碼
invoke ReleaseDC, hWnd ;釋放hDC
GetDC函數返回的hDC對應窗口的整個客戶區，當使用完畢的時候，hDC必須用ReleaseDC函數釋放。對于用GetDC獲取的hDC，Windows建議使用的范圍限于單條消息內，當程序在處理某條消息的時候需要繪畫客戶區時，可以用GetDC獲取hDC，但在消息返回前，必須用ReleaseDC將它釋放掉，如果在下一條消息中需要繼續使用到hDC，那么必須重新用GetDC函數獲取。
上面的兩種方法獲取的hDC都是窗口的hDC，如果要操作的是其他的東西，如打印機、位圖等，就不能使用BeginPaint或GetDC函數了。當繪圖的對象是一個設備的時候，可以用CreateDC函數來建立一個DC：
invoke CreateDC, lpszDriver, lpszDevice, lpszOutput, lpInitData
lpszDriver指向設備名稱，如顯示設備的設備名是DISPLAY，打印機的設備名一般為WINSPOOL，下面這幾句代碼建立的DC對應整個屏幕：
szDriver db “DISPLAY”,0
…
invoke CreateDC, addr szDriver, NULL, NULL, NULL
mov hDC, eax
當繪圖對象是位圖的時候，同樣需要一個和位圖句柄相聯系的DC，這時可以用函數CreateCompatibleDC來創建一個顯示表面僅存在于內存中的DC：
invoke CreateCompatibleDC, hDC
參數中的hDC是用來參考的DC句柄，如果指定的參數是NULL，那么建立的DC將和當前屏幕的設置兼容，為了用CreateCompatibleDC建立的DC繪畫一個位圖，還需要用SelectObject函數將hDC和位圖句柄聯系起來。
用CreateDC和CreateCompatibleDC函數建立的hDC在使用結束以后，必須用DeleteDC函數刪除，注意這里不能用ReleaseDC，這個函數是和GetDC配合用的。
用BeginPaint/EndPaint以及GetDC獲取的hDC的使用時間不能超出本條消息，與此相比，用CreateDC以及CreateCompatibleDC建立的hDC就沒有這個限制，可以在任何時刻建立它并且一直使用到不再需要為止。
三、色彩和坐標
1、Windows中的色彩
可以表示的顏色總數由顏色深度決定，也就是存儲每個像素所用的位數，各種顯示設備可以顯示的顏色總數可能大不相同，如果設備支持的顏色深度太淺，就會影響到圖像的質量，會讓人看起來覺得很粗糙和不自然。
一種顏色可以分解成紅、綠、藍三原色，所以可以用紅、綠、藍3個分量的組合來表示各種顏色。
當設備支持的顏色深度少于等于8位時（如8位（256色）、4位（16色）、2位（4色）或1位（2色）），總體位數太少，不足以用來表達3個顏色分量，這時系統建立一個色彩表，像素數據用來做索引在色彩表中獲取顏色值，所以低于8位的顏色稱為索引色。
只有當顏色深度大于8位的時候，像素數據中才直接包含紅、綠、藍3個分量。當顏色深度為16位的時候，紅、綠、藍各用5位表示，剩下的1位用做屬性位，實際可以表示的顏色數目為2^15=32 768種，16位深度的彩色又稱為16位色、高彩色或增強色。當顏色深度為24位的時候，3個分量各用8位表示，實際可以表示的顏色數目為2^24=16777216種，24位深度的彩色又稱為24位色、16M色或真彩色。對于人的眼睛來說，超過16位的顏色就已經很難分辨了。
在Win32的編程中，統一使用32位的整數表示一個深度為24位的顏色，在這32位中只使用低24位，每一種原色分量占用8位，其中0~7位為紅色，8~15位為綠色，16~23位為藍色。在程序中用到一種顏色常數的時候，可以如下使用：
move ax, 紅色 + 綠色*100h + 藍色*10000h ;將顏色放入eax中
當顯示設備無法表示24位色的時候，Windows會自動用設備可以顯示的最接近的顏色來代替它，當顯示設備的顏色深度比較低的時候，可以通過函數GetNearestColor來得知一種顏色（顏色）會被系統替換成哪種顏色：
invoke GetNearestColor, hDC, dwColor ;返回真正使用的顏色值
但是當顯示設備顏色深度太低的時候，經過Windows自動轉換的圖像可能會讓人覺得很不自然，所以在有些時候，程序員可能希望預先得知設備的顏色深度，然后根據具體情況顯示不同的圖形。
顯示設備的顏色深度可以用以下函數獲取：
invoke GetDeviceCaps, hDC, PLANES
mov ebx, dwPlanes
invoke GetDeviceCaps, hDC, BITSPIXEL
mul ebx
mov dwColorDepth, eax
第一個函數調用返回DC的色彩平面數，第二個函數調用返回每個像素的色彩位數，顏色深度最后可以通過dwPlanes乘以dwBitsPixel得到。
2、Windows中的坐標系
要用GDI函數繪圖，就必須首先了解這些函數使用的坐標系，在默認的狀態下，Windows坐標系以左上角做坐標原點，以右方當做X坐標的正方向，以下方當做Y坐標的正方向。坐標的數值要用一個有符號的16位數來表示，范圍從-32 768~32767，坐標的單位為像素。這種坐標系定義方法的好處是：窗口中每一點的坐標不會因為窗口的大小改變而改變，試想一下，如以數學中通常的表示方法，以左下角做坐標原點，那么當窗口高度被用戶調整的時候，客戶區中每一點的Y坐標都會變化，在具體使用中就會有諸多不便。
但是Windows也提供了其他的一些坐標映射方法供程序員使用，可以用SetMapMode函數來為一個DC設置新的坐標映射方法：
invoke SetMapMode, hDC, iMapMode
可以設置的參數包括坐標原點、坐標和邏輯單位和坐標的正方向等，參數中的iMapMode為新的映射方式，其可以選擇的取值如下表所示，Windows默認使用的映射方式為MM_TEXT。
Windows中可用的坐標映射方式
|
映射方式
|
原點
|
邏輯單位
|
X正方向
|
Y正方向
|
|
MM_TEXT(默認方式)
|
左上
|
像素
|
右
|
下
|
|
MM_HIENGLISH
|
左上
|
0.001英寸
|
右
|
上
|
|
MM_LOENGLISH
|
左上
|
0.01英寸
|
右
|
上
|
|
MM_HIMETRIC
|
左上
|
0.01毫米
|
右
|
上
|
|
MM_LOMETRIC
|
左上
|
0.1毫米
|
右
|
上
|
|
MM_TWIPS
|
左上
|
1/1440英寸
|
右
|
上
|
|
MM_ISOTROPIC
|
可變
|
可變（x=y）
|
可變
|
可變
|
|
MM_ANISOTROPIC
|
可變
|
可變（x!=y）
|
可變
|
可變
|
可以看到，除了默認的MM_TEXT方式外，下面5種映射方式：MM_HIENGLISH，MM_LOENGLISH，MM_HIMETRIC，MM_LOMETRIC和MM_TWIPS采用的都是原點位于左上角、X正方向向上的映射方式，另外，它們的坐標邏輯單位是不同的。
最后的兩種映射方式MM_ISOTROPIC和MM_ANISOTROPIC提供了更靈活的選擇，設置為這兩種映射方式后，程序可以繼續調用SetViewportOrgEx，SetViewportExtEx和SetWindowExtEx函數來自由設置坐標系的原點、邏輯單位和坐標的正方向等所有參數。在其他映射方式下的時候，不能使用這3個設置函數，這時任何對它們的調用都會被忽略。