• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            何苦做程序?!

            業精于勤,荒于嬉;行成于思,毀于隨! I believe , I can flying! 勿在浮砂筑高臺!

            C++博客 首頁 新隨筆 聯系 聚合 管理
              4 Posts :: 1 Stories :: 14 Comments :: 0 Trackbacks

            2006年3月11日 #

             孫鑫VC講座筆記--WINDOWS程序內部運行原理

            聲明:

                    本人最近也在看孫老師的視頻,為了加強理解,所以想一些讀書筆記。但是在CSDN上一搜索,發現已經有朋友做了相關筆記。根據面向對象的“繼承”觀點,為了解決勞動力,所以我打算在他們的基礎上添加、修改。應該不涉及著作權什么的東東吧?!

                    我在BLOG.CSDN.NET/LEWISLAU上搜索了下 ,有兩位朋寫了相關筆記(而且都是一樣的)。不知道誰才是原作者,所以列出兩位BLOG地址:

            http://blog.csdn.net/hhitjsj021                                http://blog.csdn.net/d007879

            以后我會在前輩的基礎上修改、發文!呵呵!繼承嘛!

             

             

             

             

            windows程序設計是種事件驅動方式的程序設計,主要基于消息的。當用戶需要完成某種功能時,需要調用OS某種支持,然后OS將用戶的需要包裝成消息,并投入到消息隊列中,最后應用程序從消息隊列中取走消息并進行響應。

             

            MSG Structure

            --------------------------------------------------------------------------------

            The MSG structure contains message information from a thread's message queue.

            Syntax

            typedef struct {
                HWND hwnd;   //指示一個窗口的句柄,改消息和那個窗口相關聯。
                UINT message;  //具體的消息,用無符號整形表示
                WPARAM wParam; //關于消息的附加參數
                LPARAM lParam; //同上
                DWORD time; //32位整數,表示消息被投遞出去的時間
                POINT pt; //表示光標位置
            } MSG, *PMSG;

             句柄,資源的標識,操作系統通過句柄指到資源。常見的句柄有圖標句柄(HICON),光標句柄(HCURSOR),窗口句柄(HWND),應用程序句柄(HINSTANCE)
             
            例如:當按下按鍵會發送出WM_CHAR消息   通過消息的附加參數,保存對應的ASCII碼,即可知道按下的是那個鍵。

             

             


            消息隊列:
            每個應用程序OS都為它建立一個消息隊列,消息隊列是個先進先出的緩沖區,其中每個元素都是一個消息,OS將生成的每個消息按先后順序放進消息隊列中,應用程序總是取走當前消息隊列中的第一條消息,應用程序取走消息后便知道用戶的操作和程序的狀態,然后對其處理即消息響應,消息響應通過編碼實現。

            使用VC編程除了良好的C基礎外還需要掌握兩方面:
            一,消息本身。不同消息所代表的用戶操作和應用程序的狀態。
            二,對于某個特定的消息來說,要讓OS執行某個特定的功能去響應消息。


            Window程序入口:
            int WINAPI WinMain(
              HINSTANCE hInstance,  // 當前事例句柄。
              HINSTANCE hPrevInstance,  // 先前事例句柄。
              LPSTR lpCmdLine,      // 命令行指針
              int nCmdShow          // (窗口)顯示的狀態
            );
            說明:WinMain函數是Windows程序入口點函數,由OS調用,當OS啟動應用程序的時候,winmain函數的參數由OS傳遞的。

             

            創建一個完整的窗口需要經過下面四個操作步驟:
            一,設計一個窗口類;如:WNDCLASS wndcls;
            二,注冊窗口類;    如:RegisterClass(&wndcls);
            三,創建窗口;      如:CreateWindow(),CreateWindowEX();
            四,顯示及更新窗口。如:ShowWindow(),UpdateWindow();
            說明:創建窗口的時候一定要基于已經注冊的窗口類.

             

             

            Windows提供的窗口類:
            typedef struct  WNDCLASS {
                UINT    style;        //窗口的類型
                WNDPROC lpfnWndProc;  //窗口過程函數指針(回調函數)
                int     cbClsExtra; //窗口類附加字節,為該類窗口所共享。通常0。
                int     cbWndExtra; //窗口附加字節。通常設為0。
                HANDLE  hInstance;  //當前應用程序事例句柄。
                HICON   hIcon;      //圖標句柄 LoadIcon();
                HCURSOR hCursor;    //光標句柄 LoadCursor();
                HBRUSH  hbrBackground; //畫刷句柄 (HBRUSH)GetStockObject();
                LPCTSTR lpszMenuName;  //菜單名字
                LPCTSTR lpszClassName; //類的名字
            } WNDCLASS,*PWNDCLASS;


            窗口類型style為一個變量,該變量每一位對應著一種特性。對應為1時,有該種特性;對應為0時,無該種特性。為了方便記憶,用一些宏對應一些特征,通過取反(~)和相與(&)可以取消一些特性。  通常設置為"CS_HREDRAW | CS_VREDRAW"表示垂直重繪和水平重繪。

            HICON可以由LoadIcon 賦值(它有兩個參數HINSTANCE和LPCTSTR,通常第一個參數為空,只對第二個參數賦值,即圖標的ID)
            HCURSOR同HICON
            HBRUSH 使用GetStockObject函數,它可以用來獲取筆、畫刷、字符、調試板的畫刷。使用時要用HBRUSH做一直強制轉化。因為GetStockObject返回值和HBRUSH不同。

            窗口類注冊:
            ATOM RegisterClass(
              CONST WNDCLASS *lpWndClass   // address of structure with class
                                          // data
            );
            //注意,是使用地址符

             


            創建窗口:
            HWND CreateWindow(
              LPCTSTR lpClassName,  //注冊窗口類名,用引號
              LPCTSTR lpWindowName, //窗口標題,用引號
              DWORD dwStyle,        //窗口類型(風格)通常為(WS_OVERLAPPEDWINDOW)
              int x,                // 窗口X坐標
              int y,                // 窗口X坐標
              int nWidth,           // 寬度
              int nHeight,          // 高度
              HWND hWndParent,      // 指向父窗口的句柄
              HMENU hMenu,          // 菜單句柄
              HANDLE hInstance,     // 當前實例的句柄,由WINMAIN傳遞
              LPVOID lpParam        // WM_CREATE附加參數傳入指針
            );
            創建窗口的時候會發送WM_CREATE消息


            顯示和更新窗口窗口:
            BOOL ShowWindow(
              HWND hWnd,     // handle to window
              int nCmdShow   // show state of window
            );
            BOOL UpdateWindow(
              HWND hWnd   // handle of window  送出WM_PAINT消息
            );


            消息循環
            MSG msg;
            while(GetMessage(&msg,...))    //從消息隊列中取出一條消息
            {
             TranslateMessage(&msg); //進行消息(如鍵盤消息)轉化。轉化過程不會影響原消息,只會創建新的消息。
             DispatchMessage(&msg); //分派消息到窗口的回調函數處理,(OS調用窗口回調函數進行處理)。
            }

            BOOL GetMessage(
              LPMSG lpMsg,         // 消息結構體變量
              HWND hWnd,           // 句柄,那個一個窗口?為NULL則為所有窗口句柄
              UINT wMsgFilterMin,  // 最小消息值,為0時返回所有消息
              UINT wMsgFilterMax   // 最大消息值
            );

             

            回調原理:當應用程序受到給某個窗口的消息時,就應調用某一函數來處理這條消息。這一消息有操作系統自動完成。

            注:函數名可以用以表示函數代碼的首地址(函數指針),額外數據通常為0。


            窗口過程函數(回調函數)原型:
            LRESULT CALLBACK WindowProc(  //這里WindowProc是個代號名字。
              HWND hwnd,      // handle to window
              UINT uMsg,      // message identifier
              WPARAM wParam,  // first message parameter
              LPARAM lParam   // second message parameter
            );
            說明:兩種函數調用約定(__stdcall 和 __cdecl):
            #define CALLBACK    __stdcall
            //__stdcall 標準調用預定,是PASCAL 調用約定,象DELPHI使用的就是標準調用約定
            #define WINAPIV     __cdecl 
            // __cdecl 是C 語言形式的調用約定。
            主要區別:函數參數傳遞順序 和 對堆棧的清除上。
            問題:除了那些可變參數的函數調用外,其余的一般都是__stdcall約定。但 C/C++編譯默然的是__cdecl約定。所以如果在VC等環境中調用__stdcall約定的函數,必須要在函數聲明的時加上 __stdcall 修飾符,以便對這個函數的調用是使用__stdcall約定(如使用DELPHI編寫的DLL時候)。
            (VC中可通過這途徑修改:project|settings..|c/c++|...)
            在窗口過程函數中通過一組switch語句來對消息進行處理:
            如:
            LRESULT CALLBACK WindowProc( 
              HWND hwnd,
              UINT uMsg,
              WPARAM wParam,
              LPARAM lParam  
            )
            {
                switch(uMsg)
                {
             case WM_PAINT:
              ...
              break;
             case ...
              break;
             case WM_CLOSE:
              //DestroyWindow(hwnd);
               //銷毀窗口,并發送WM_DESTROY消息。
              break;
             case WM_DESTROY:
              //PostQuitMessage(0);
              //發送WM_QUIT消息到消息隊列中,請求終止。
                     //GetMessage()取到WM_QUIT消息后,返回0,退出消息循                //   環,從而終止應用程序。
              break;
             default:
              return DefWindowProc(hwnd,uMsg,wParam,lParam);
             //用缺省的窗口過程處理我們不感興趣的消息(其它消息)。
             //這是必須的。
                }//switch
             return 0;
            }//WindowProc


             響應WM_DESTROY,調用PostQuitMessage(int)結束進程。它會投遞一個WM_QUIT消息對消息隊列中。當消息循環的GetMessage取到WM_QUIT消息,則返回0,程序結束。
             另外對于不感興趣的消息要景象缺省的處理,使用DefWindowProc()內為窗口的參數。

             


            關于DC句柄獲取:
            a)使用BeginPaint(),EndPaint()對。注意只能在響應WM_PAINT消息時使用。
            b)使用GetDc(),ReleaseDC()對。注意他們不能在響應WM_PAINT中使用

            posted @ 2006-03-11 11:19 lewislau 阿木 閱讀(2682) | 評論 (1)編輯 收藏

             【原創】我在成都當程序員

            題記:前幾天出去感受一下,感觸頗深,發覺自己真的很遜。現在回到清靜的校園,自己覺得應該更加努力。社會真的不是我們想的那樣,工作也不像學習一樣輕松。只希望各位朋友在走出校門,邁向社會的過程中,一切順利!

             在成都待了一個星期,確切的說只有六天。在這六天里面,我完完全全是一個打工的,一個社會上的人,一個程序員。聽上去多牛B,程序員啊,這個可是我夢寐以求的職業啊,可是事實上一切都不是我想的那樣輝煌。我這幾天腦海里反復浮現一句話,程序員的的確確是十分辛苦的職業。
             我所在的公司是一家游戲外掛公司,專門做游戲外掛。從社會的角度來說,這種“勾搭”只能暗箱操作,如今卻還明目張膽的“開張營業”,確實搞笑;從技術的角度來說,游戲外掛,利用HOOK攔截數據包、解密、修改、封包,樣樣都是安全方面的比較牛B的技術,在沒有進這個公司之前,我沒有想過一年以內會接觸到這些底層的技術。所有說公司對我來說,有些失望、但是也有一些期望。
             以前在綿陽(家鄉)的一些小IT公司也玩兒過,但是這次是獨自在外,什么問題都要自己解決,所有從各個方面來說,都是自己的一些新的嘗試。不過還好的是,這次我是和朋友一切去成都“實習”。呵呵,不過我比他好的就是,他在電信設計規劃院實習三個月,沒有實習工資,三個月轉正;而我實習一個月實習工資一千,一個月后轉正,根據情況而定工資,表現的好的話在3K左右(聽上去挺吸引人的,但是真的很累)。
             我們到成都只用了2個小時找了一處住房,合租,350一月,只有一張床和一個書桌(天啦,成都的房價真TMD的嚇死人)。唯一比較欣慰的是我們住在川大外面,步行到川大只要5分鐘,原先設想的是每天下班去川大教室去上自習,可是現實往往與設想有很大的差距,每天回到家累的簡直書都不想看。(白天在公司至少看6個小時以上的文檔,對這那個15寸的CRT,我簡直萬分的不爽,公司里面50多人就我一個用CRT顯示器,我靠,欺負我??!)每晚和朋友在川大轉悠兩圈就回去睡覺,這種生活,讓我回憶起兩歲的時候家里還不景氣的狀態。汗!
             言歸正轉,還是說工作的事兒,每天我7:40起床,解決完所有問題大約8:20到達車站,搭上19路,順利的話8:55作用能到達高升橋(公司所在地),唉,不禁汗顏,每天要白白浪費大約90分鐘時間搭車,在成都人看來,這還算近的(大城市的是比我們這些農民洋盤)。9點左右到達公司,不出意外的話只有我旁邊的仁兄比我早到。(公司老大考慮技術部經常加班,所以允許技術部的兄弟們9:30上班,這個還夠人性化。)這位仁兄待會要重點介紹,公司里面就跟他混的最熟,特牛B。說到加班,我突然想起才去公司和技術部老大談的時候,老大特別交代,“如果你加班的話,晚上可以打車回家。拿上小票,第二天回公司報銷。”我汗,原來這個公司加班就跟喝水一樣隨便。
             我才到公司,我的工作就是不停的看文檔,中文的、英文的都看。(我都懷疑我居然能看懂英文)老大給我的任務很簡單,就一句話:“利用HOOK抓取程序的數據包。”他還特別交代,“不需要你解密數據包,抓取就可以”看上去降低了很大難度哦,但是有兩個人能證明這個我這個公司不是我現在的水平能夠接受的。第一個馮SIR,他說這個東西對于我來說,非常非常具有挑戰,希望我能創造奇跡。(汗,奇跡!)第二個是李SIR,回學校后我給他講述我的“作業”,他說,哦,這個東西和我師兄研究生的畢業設計很像。(我再一次汗顏)我承認自己的喜歡有挑戰的工作,但是我還是很有自知之明,確切的說我很自量力。
             我每天的工作就是看文檔,看的我要瘋,HOOK屬于WINDOWS的核心技術,趨于操作系統底層,用于攔截操作系統發出的消息。對于我來說決不是簡單的事兒,所以不敢懈怠,我每天就GOOGLE,MSDN上搜尋關于它的一切,中文的英文的都看,要瘋!看看我旁邊的家伙,現在就來說說他,他是測試部的,他的工作就是不停的耍各種各樣的游戲(居然耍游戲真的能找到工作,我簡直為我們學校的兄弟們感到欣慰),有的時候網速比較卡,他沒法耍游戲,就只能委屈一下看小說,這樣的工作讓我羨慕的不行。偶爾看到他再不斷的抄錄房產信息,就問他是否要買房。他說,恩。我就納悶了,看上去年紀輕輕的就想房子,公司耍游戲的難不成拿8K一個月?繼續問到,“你工作幾年了哦?都有錢買房了?”“我工作了都五年了,我一個月1500,一年存不到5000。靠自己的話都不知道什么時候才能買哦、。其實是我父母給錢。”終于發現一個比我還強的人了。事后,我給我爸媽打電話匯報我的近況,閑聊到此事兒,只聽電話那邊一片寂靜,我爸耍句“你給我說這些,難不成你還要我們給你準備錢買房子?”(上帝作證,我絕對沒那么想)。
             每天吃午飯大約半小時不面對那可惡的CRT,其余時間就逃不過浩劫,現在用到筆記本是爽哦,至少不是CRT的。公司里面基本上都要玩兒游戲,還有人被盜過帳號。(我們都是干地下生意的,還被人家黑吃黑?!)我就想,寫個木馬對于我們公司的幾個高手來說絕對是小菜一碟,但是自己的帳號被盜了還是沒辦法,說不定就是自己的木馬盜的自己的帳號。
             公司還有一個女程序員,佩服啊。今天也是三八婦女節,向牛B的女程序員致敬!
             每天下午六點,其實那個時候我都可以離開了,但是技術部所有同僚加班(除了我,因為我是新來的,還做不了事兒。)所以我也不好走的太快,慢慢騰騰的磨到六點一刻才離開公司,回家咯。
             上面所有行文,也許你還沒感覺到辛苦,因為有些細節的事兒再說說:
             我每天上班搭乘公車,大約一共要站90分鐘,絕對有少無多。上班還好,人并不多;我大概描述下我下班的情況,我第一天下班等了兩輛19路后換成77路,結果多步行了四十分鐘的樣子,到家的時候都快20:30了,還沒吃飯。后來我搭19路,大概情況是,本來是前門透幣上車的,我只能從后門上,上車后貼在車門,途中路過要下車的我還要從后門下來讓別人下車。我靠,這下感覺到毛大爺真不對,啥子人多力量大,瞎扯!
             回到住的地方,吃過飯的時間是最難打發的。以前在家熬夜,也不可能睡的太早,大概每天就十一點的樣子睡,期間的時間就不知道如何處理?!一切在家時候就玩兒電腦,現在連個電視都看不到,感覺自己都與外界隔絕了一樣。每天就到川大的散散步步,然后回住的地方躺在床上,發幾條短信,打幾個電話,便早早的睡去。這個是讓我精神上最難以忍受的地方。我靠,我是IT人哦?信息時代哦?!這到底是什么見鬼的生活,我最受不了就是這一點。不過還好,我是和朋友一起出來的,晚上還可以閑聊幾句,不過想想以后要是一個人出門在外,我估計自己早晚要瘋。
             晚上,書也不想看,要是以后還是這個樣子,我估計這輩子就只能當一輩子的垃圾程序員了。
             有的時候我想,程序員的確非常辛苦,自己選擇這條道路對不對。后來想了想,努力做好每一件事兒,總有一天我相信自己的能力得到鍛煉以后,我相信態度決定一切。
             唉,現在回到學校了,真的很多感悟,大家還是一起努力吧!
             現在感覺做程序真的很累,而且付出和收入顯然不是成正比的,現在有點上了賊船又無法回頭,仔細想想又有點相追求庫克船長那樣傳奇的人生,矛盾!

            posted @ 2006-03-11 11:18 lewislau 阿木 閱讀(974) | 評論 (8)編輯 收藏

            2006年2月18日 #

             MFC程序設計
                         之來龍去脈
             題記:前些日子一直想寫這個東西,做了一個開頭放在我的BLOG上(但是名為<MFC框架程序WINMAIN函數分析>),到后來就沒有再管了,其實那只是冰山一角.具體MFC是怎么運行的,還是沒有交待清楚,雖然自己的BLOG很少有人光顧,但是本著做事兒就要做到底的心態,繼續完成該文。
             說明:1、本文作者在VS2003中跟蹤代碼,此代碼為VS2003中拷貝,使用MFC7。
                   2、不同框架的MFC程序由所不同,本文以單文檔為例。
                      3、本文讀者需要有一定的SDK的基礎,不需要太多,至少知道它的基本框架和來龍去脈即可!
                      4、文章只想起到說明作用,所以代碼會有一些刪除。
             學MFC,竟然還不知道MFC的MAIN函數在什么地方?怎么運行的?實在不高明。
             看過候捷(JJHOU)老師的《深入淺出MFC》的,對它一定很熟悉。呵呵,本文是獻給沒有看過那本書,但是又很希望學習MFC程序設計的朋友的。(沒有看過那本書的朋友還不趕快去買?)其實本文,主要是對《深入淺出MFC》第六章的一個總結和補充罷了!(本文有該書不同的地方,也有一些筆者自己的見解!)
             言歸正傳。
             假如你用AppWizard一步一步NEXT下來,然后在CLASSVIEW中去找尋WINMAIN函數,那么你只有失望。MFC最大的特點是什么?封裝!MFC的確封裝的太好了,以至于很多想學習MFC的人都望而卻步。閑話少說,還是繼續我們今天的話題,MAIN函數!實話告訴你吧,即使你搜索所有的MFC生成的文件,都無法發現WINMAIN的字眼,那么它就近在什么地方呢?
             我相信你已經想到,MAIN函數應該在主要的應用程序文件中。難道是“您定義的程序名.cpp”這個文件?不錯就是它。再Crtl+F一下,看有沒有我們要找的WINMAIN函數?看來你又要失望了,但是你注意有這樣一句:
             
            /////////////////////////////////////////////////////////////////////////////
            // The one and only CMyApp object

             CMyApp theApp;   //本人建立的工程名為My。
             
             
             是不是很特別,再注意一下那句注釋“The one and only CMyApp object”,每個應用程序有且只用一個CMyApp對象。我想你應該想到了,WinMain函數每個程序也只能有一個,那么這個全局對象跟WinMain函數肯定有莫大的關系?沒錯,相信你的直覺。
             特別注意:深曉C++細節的人一定知道,全局對象優先于MAIN函數執行的道理。如果你不知道也沒關系,那么我在這里告訴你:“全局對象優先于MIAN函數執行,且構建于棧中,切記,切記!”
             現在,我們該深入WinMain運行機制了,確切的說,應該是MFC的機制!
             首先,看看MFC的庫文件把,它能給我們帶來許多驚喜。(vc6的相應的目錄是\Microsoft Visual Studio\VC98\MFC\SRC;VC7相應的目錄是\Microsoft Visual Studio .NET 2003\Vc7\atlmfc\src\mfc)
             現在我們就從這個全局下手,開始今天的旅途。
             CMyApp theApp;
             此時,系統會執行CMyApp的父類(CWinApp)構造函數,再執行CMyApp的構造函數。(先有老爹,再有兒子!),此時就會調用CWinApp的構造函數。
             
             CWinApp的構造函數(在VC提供的MFC代碼中以“文中的一個字或詞組”的方式查詢關鍵字,此時打開APPCORE.CPP,以下使用相同搜索方式,不再復述。)找到以下內容:
             CWinApp::CWinApp(LPCTSTR lpszAppName)
             {
              if (lpszAppName != NULL)
               m_pszAppName = _tcsdup(lpszAppName);
              else
               m_pszAppName = NULL;
             
              // initialize CWinThread state
              AFX_MODULE_STATE* pModuleState = _AFX_CMDTARGET_GETSTATE();
              AFX_MODULE_THREAD_STATE* pThreadState = pModuleState->m_thread;
              ASSERT(AfxGetThread() == NULL);
              pThreadState->m_pCurrentWinThread = this;
              ASSERT(AfxGetThread() == this);
              m_hThread = ::GetCurrentThread();
              m_nThreadID = ::GetCurrentThreadId();
             
              // initialize CWinApp state
              ASSERT(afxCurrentWinApp == NULL); // only one CWinApp object please
              pModuleState->m_pCurrentWinApp = this;
              ASSERT(AfxGetApp() == this);
             ... ...
             }
             OK,就到這里就可以了,仔細看上面代碼,它已經完成了應用程序線程額的啟動,它給予了我們程序的生命。現在請注意:
                    pThreadState->m_pCurrentWinThread = this;
             pModuleState->m_pCurrentWinApp = this;
                 這兩行代碼其實都是做的一件事兒。
                 這段代碼的意思是,獲得了CMyApp的全局對象的this指針。(此時你肯定要疑問,為什么是CMyApp的指針?this目前是在CWinApp中啊?   對此我的答案是,可是你是由CMyApp的對象引發的CWinApp的構造啊!!)這個指針可非一般的人物,稍后我們的很多工作都要靠它完成。
                 CWinApp之中的成員變量將因為theApp這個全局對象的誕生而獲得配置和初始值。
              構造完父類,現在構造子類。可是我們看到,AppWizard給我們的子類里它什么也沒做?是的,這一切都聽從你的安排!
                CMyApp::CMyApp()
                {
             // TODO: add construction code here,
             // Place all significant initialization in InitInstance
             }
             
             
             
              接下來就是今天的主角兒了,搜索關鍵字“WinMain”,出現很多文件。別急,因為現在我們應該先看看WinMain的聲明。打開appmodul.cpp:

                 _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
             LPTSTR lpCmdLine, int nCmdShow)
             {
             // call shared/exported WinMain
             return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
             }
             
            這里_tWinMain是為了支持UNICODE而命名的一個宏,真正起作用的是AfxWinMain,注意看看它的參數,是不是和SDK的WinMain函數一樣?
             現在再搜索下AfxWinMain,其實在winmain.cpp中:
             
            int AFXAPI AfxWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
             LPTSTR lpCmdLine, int nCmdShow)
            {
             ASSERT(hPrevInstance == NULL);

             int nReturnCode = -1;
             CWinThread* pThread = AfxGetThread();
             CWinApp* pApp = AfxGetApp();

             // AFX internal initialization
             if (!AfxWinInit(hInstance, hPrevInstance, lpCmdLine, nCmdShow))
              goto InitFailure;

             // App global initializations (rare)
             if (pApp != NULL && !pApp->InitApplication())
              goto InitFailure;

             // Perform specific initializations
             if (!pThread->InitInstance())
             {
              if (pThread->m_pMainWnd != NULL)
              {
               TRACE(traceAppMsg, 0, "Warning: Destroying non-NULL m_pMainWnd\n");
               pThread->m_pMainWnd->DestroyWindow();
              }
              nReturnCode = pThread->ExitInstance();
              goto InitFailure;
             }
             nReturnCode = pThread->Run();
            ... ...
            }
             此段代碼注意五個細節:
             CWinApp* pApp = AfxGetApp();
             意為獲得對象指針,其實就是剛才那個THIS。不記得了?指向CMyApp的那個!還值得注意的是,Afx意是全局的,隨時你都可以調用它。(AFX就是MFC開發小組的開發代號,意為Application Framework 傳說X只是為了好看,沒實在意思?!)
             if (!AfxWinInit(hInstance, hPrevInstance, lpCmdLine, nCmdShow))
             AfxWinInit完成了線程的初始化和窗框類的注冊。具體參看appinit.cpp中的定義。
             if (pApp != NULL && !pApp->InitApplication())
             其實pApp和pThread是同一個指針,都是指向CMyApp的指針,這里因為CMyApp中沒有定義InitApplication,實際上就調用的CWinApp::InitApplication(),完成了MFC的內容管理。
             if (!pThread->InitInstance())
             因為CMyApp中改寫了它,所以調用CMyApp中的,其實它也是初始化工作。此時也完成了默認窗口類的定義。假如你熟悉SDK編程的話,一定不會忘記窗口類的設計、注冊、創建、現實及更新的步驟,此時MFC以為你設計好了默認的窗口類。
             現在你不禁要疑問,InitApplication()和InitInstance()有何不同?
             答案是,假如你執行一個程序,于是兩個函數都會被調用;當你在不關閉前一個程序的前提下,再執行一個程序,那么就只執行后一個函數。
             nReturnCode = pThread->Run();
             這個一步驟在《深入淺出MFC》中被成為程序的活水源頭,在我看來它就是你開車踩油門的步驟。待會我們會具體闡述!
             
             在設計窗口類以后,就應該是注冊,MFC自動調用(跳轉到)AfxEndDeferRegisterClass(WINCORE.CPP中),為你注冊了五個窗口類,分別是:AfxWnd,AfxCreateBar,AfxMDIFrame,AfxFrameOrView,AfxOleControl以上窗口類MFC將自動轉化成獨立無二的類名,供其調用。
             在窗口的注冊以后,就應該是窗口的創建工作,此時會調用CFrameWnd::Create(),該代碼位于WINFRM.Cpp中
            BOOL CFrameWnd::Create(LPCTSTR lpszClassName,
             LPCTSTR lpszWindowName,
             DWORD dwStyle,
             const RECT& rect,
             CWnd* pParentWnd,
             LPCTSTR lpszMenuName,
             DWORD dwExStyle,
             CCreateContext* pContext)
            {
             HMENU hMenu = NULL;
             if (lpszMenuName != NULL)
             {
              // load in a menu that will get destroyed when window gets destroyed
              HINSTANCE hInst = AfxFindResourceHandle(lpszMenuName, RT_MENU);
              if ((hMenu = ::LoadMenu(hInst, lpszMenuName)) == NULL)
              {
               TRACE(traceAppMsg, 0, "Warning: failed to load menu for CFrameWnd.\n");
               PostNcDestroy();            // perhaps delete the C++ object
               return FALSE;
              }
             }

             m_strTitle = lpszWindowName;    // save title for later

             if (!CreateEx(dwExStyle, lpszClassName, lpszWindowName, dwStyle,
              rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top,
              pParentWnd->GetSafeHwnd(), hMenu, (LPVOID)pContext))
             {
              TRACE(traceAppMsg, 0, "Warning: failed to create CFrameWnd.\n");
              if (hMenu != NULL)
               DestroyMenu(hMenu);
              return FALSE;
             }

             return TRUE;
            }
             
             其中完成了窗口的創建工作,里面還涉及擴展風格的調用CreateEx,具體細節請參看MSDN。
             
             此時你不禁要問,我們的事兒都讓MFC做完了?工業化生產出來的窗口都是千篇一律啊,我要有我自己的風格!
             別急,MFC給用戶提供了一個修改窗口設計的機會那就是:PreCreateWindow(CREATESTRUCT& cs) 你在MSDN中查詢一下CREATESTRUCT這個結構體,你會發現它和我們的CreateWindow幾乎是一模一樣,這個就是MFC留給你修改窗口的一個機會。在PreCreateWindow時,會跳到CWnd::PreCreateWindow,里面有一個宏:AfxDeferRegisterClass,它的作用是:如果該窗口類沒有被注冊,那么就注冊它;如果注冊了,就什么也不管!
             窗口類的設計、注冊、創建都已經完成,現在只剩下更新和顯示了。這些工作都交由 CMyApp::InitInstance()完成:
              m_pMainWnd->ShowWindow(SW_SHOW);
              m_pMainWnd->UpdateWindow();
             現在if (!pThread->InitInstance())的工作已經完成,按照MAIN函數的內容,接下來該:nReturnCode = pThread->Run()了
             此時應該調用CMyApp的Run()函數,但是在CMyApp類中,根本沒有聲明或定義這樣一個函數,根據多態性的原來,指針遷升,指向CWinApp::Run(),其代碼位于APPCORE.CPP中:
             
             int CWinApp::Run()
             {
              if (m_pMainWnd == NULL && AfxOleGetUserCtrl())
              {
               // Not launched /Embedding or /Automation, but has no main window!
               TRACE(traceAppMsg, 0, "Warning: m_pMainWnd is NULL in CWinApp::Run - quitting application.\n");
               AfxPostQuitMessage(0);
              }
              return CWinThread::Run();
             }
             
             最后你會發現,它由調用了一個CWinThread::Run(),此時你就看不到CWinThread::Run()的代碼了(至少筆者沒有找到,因為微軟只提供了部分MFC代碼。)但是你可以在MSDN中找到CWinThread::Run()的描述:
             Run 控制線程的函數。包含消息泵。一般不重寫。
             再具體點就是:
             Run acquires and dispatches Windows messages until the application receives a WM_QUIT message. If the thread's message queue currently contains no messages, Run calls OnIdle to perform idle-time processing. Incoming messages go to the PreTranslateMessage member function for special processing and then to the Windows function TranslateMessage for standard keyboard translation. Finally, the DispatchMessage Windows function is called.
             Run is rarely overridden, but you can override it to implement special behavior.
             This member function is used only in user-interface threads.
             原來它把消息循環包裝了一下,在MFC中稱為消息映射(message map)的東西!至于消息映射的具體細節本人會另寫文章說明!
             OK,MFC不再神秘,掌握了它的來龍去脈,再看其他的MFC書籍的時候,就知道我該怎么做?為什么我要這樣做?起到了知其然又知其所以然的效果,這就是我所追求的技術境界。
             
             

            posted @ 2006-02-18 12:04 lewislau 阿木 閱讀(4036) | 評論 (3)編輯 收藏

            2006年2月1日 #

            修煉之道
                首先聲明我不是一個“人才”,我是一個垃圾,不過我還在苦心修煉成為所謂的“人才”!在我“修煉”過程中頓有所悟,寫些隨筆,隨便涂鴉之筆。
                但凡世間萬物,無一能夠逃脫一個“道”字!我不是道教的FANS,但是我還是對其所謂的“道”,存有敬意!可惜小生修行太淺,還說不出一個所以然出來。可是,每每回想以前自己走過的點點滴滴,若有所悟?!
                每次看書學習技術的時候,總覺得少了些什么?!
                從現在開始我應該每天問自己:“技術進步了嗎?!思想呢?文化呢?”
                技術,是大家都非常想追求的。思想是可以交流的。文化呢?不要說不知道文化為何物?中華五千年的傳統文化,各位都修煉的如何?!我知道自己已經缺失了這一課程,所以從現在開始我要努力補上。
                隨便涂鴉之筆,只是提醒各位,技術之路漫長而遙遠,就算你走到盡頭也不一定稱的上“合格的人才”。
                我們經常說“提高知識文化”,彷佛大家沒有深刻的體味這句話:知識是知識,文化是文化,兩者是不相同的!
                所以在此提醒各位“在鍵盤上耕耘未來的人”,在你修煉技術的同時,別忘了文化修為的提高,當然思想也是很重要的!
            posted @ 2006-02-01 23:00 lewislau 阿木 閱讀(485) | 評論 (1)編輯 收藏

            僅列出標題  
            久久国产色AV免费观看| 91久久精品国产91性色也| 久久综合给合综合久久| 四虎影视久久久免费| 精品熟女少妇AV免费久久| 久久丫精品国产亚洲av| 国产精品视频久久| 亚洲а∨天堂久久精品| 色综合久久中文字幕无码| 狠狠色噜噜狠狠狠狠狠色综合久久| 97热久久免费频精品99| 久久综合伊人77777| 久久人人妻人人爽人人爽| 国产精品狼人久久久久影院| 午夜精品久久久久成人| 91精品国产高清久久久久久io| 色欲综合久久躁天天躁| 久久久久亚洲av无码专区| 久久久久18| 亚洲国产成人久久精品影视| 综合久久国产九一剧情麻豆| 久久本道久久综合伊人| 九九久久99综合一区二区| 久久久久久久久久久| 久久一区二区免费播放| 99久久精品免费| 久久精品视频网| 精品国产VA久久久久久久冰 | 日本五月天婷久久网站| 日韩精品久久久久久| 久久精品国产网红主播| 久久久久久久久久久| 久久久久亚洲av成人网人人软件 | 久久久久99精品成人片欧美| 伊人久久亚洲综合影院| 亚洲国产婷婷香蕉久久久久久| 久久成人国产精品一区二区| A级毛片无码久久精品免费| 久久精品国产福利国产秒| 久久国产精品-久久精品| 国产成人精品免费久久久久|