要給項目中增加一個新的模塊，需要先在服務器端做一些圖片處理相關的工作。本來，對圖片
做一些諸如ALPHA混合旋轉縮放的操作，在游戲客戶端應該是很容易的事。但是這事要在服務
器做，就不得不引入一些第三方庫。反正我們的服務器運行于WINDOWS下，這里又需要處理
JPG圖片的加載，我就考慮到了GDI+。
在這之前對GDI+沒有過任何接觸。直接翻了MSDN，還好居然有個一系列的usage。GDI+的Image
本身支持JPG的直接載入。但是并沒有我理想中的CreateFromMemory( const void *buf )接口。
看起來唯一可以從內存創(chuàng)建Gdiplus::Image對象的方法是從一個叫IStream*的COM東西。我揣摩
微軟為什么沒有提供我理想中的那個接口，或者說要把GDI+設計成這樣，可能還是考慮到對多語
言的支持。于是問題轉換為如何將一個C語言的const void*轉換為IStream*。我甚至在開始的時候
感覺到是不是要自己實現(xiàn)個Stream。后來在google上找到了一個似乎是標準的方法：首先創(chuàng)建個
HGLOBAL對象，然后通過GlobalLock就可以將一個C的const void*直接memcpy到這個HGLOBAL
里，最后，通過CreateStreamOnHGlobal這樣的接口就可以得到一個IStream。
惡心的是，基于之前對服務器內存使用的優(yōu)化，我現(xiàn)在對于內存的使用非常敏感（誰說現(xiàn)在內存
大了就可以任意malloc了？？）。上面那個過程對于資源的管理在MSDN文檔中似乎顯得有點
模糊。CreateStreamOnHGlobal函數(shù)的第二個參數(shù)指定當IStream->Release的時候，是否會自動
刪除這個HGLOBAL對象。我雖然對COM不懂，但也知道它的對象是基于一種引用計數(shù)的管理方式。
逐字看了下文檔，發(fā)現(xiàn)一個final單詞，原來是IStream->Release最后一次釋放時，會同時釋放掉
這個HGLOBAL對象。更讓人發(fā)指的是，我猜測Image( IStream * )來創(chuàng)建Image時，Image又
會對這個IStream進行一次AddRef。我發(fā)覺MSDN對于Gdiplus::Image::FromStream函數(shù)的說明
也有點模糊。我揣摩使用FromStream獲得的Image*，是否需要手動去delete？這個地方的內存
資源管理，一定得搞個水落石出。結果是，F(xiàn)romStream的實現(xiàn)就是簡單地new了個Image。而
Image內部肯定會對IStream進行AddRef，并且，如果在Image銷毀前銷毀這個HGLOBAL，這個
Image基本也就廢了。
也就是說，Image本身不對HGLOBAL中的圖片數(shù)據(jù)進行復制。囧。別想讓我再寫個wrap class把
HGLOBAL和Image糾結在一起，簡單考慮，將CreateStreamOnHGlobal第二個參數(shù)設為TRUE。
要將一個Image保存為一段內存，也比較麻煩。我的方法和google上的相同。當然，微軟的庫依
然讓我在很多細節(jié)上栽跟斗（如前所說，可能這是基于多語言支持的考慮）。首先需要創(chuàng)建個空
的IStream，即CreateStreamOnHGlobal第一個參數(shù)為NULL。然后將Image Save到這個IStream。
再根據(jù)該IStream::Seek獲取其大小，自己再分配段內存，最后IStream::Read讀取進來。同樣，
需要注意相關內存資源的管理。
下午簡單把以上兩個過程簡單封裝了下。
下載代碼。