• <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>

            winlinglin

            Windows API(1) WinMain函數

            誰是第一個Windows API?無可置疑,當然是WinMain Function啦。
            MSDN上說:The WinMain function is the conventional name for the user-provided entry point for a Microsoft Windows-based application.
            即:WinMain函數是Microsoft的一個傳統函數命名,它是提供給用戶的Windows應用程序的入口點。
            它的函數聲明如下:
            int WINAPI WinMain(         
             HINSTANCE hInstance,
                HINSTANCE hPrevInstance,
                LPSTR lpCmdLine,
                int nCmdShow
            );
            寫慣C++ console程序的人可能會很奇怪,main函數一般不是這樣寫嗎( int main() )?怎么會在函數聲明中間加了個詞(WINAPI)呢?
            其實WINAPI是一個宏,MSDN上說:Calling convention for system functions. This type is declared in WinDef.h as follows: #define WINAPI __stdcall
            那么WINAPI就是指_stdcall了。
            在網上查了一下,_stdcall還有其他同類,_cdecl _pascal _fastcall...怎么那么多的?
            _stdcall _cdecl _pascal _fastcall這些關鍵字是什么意思,有什么區別呢?
            在網上查了一下,總結一下答案:
            (1)其實它們就是關于堆棧的一些說明,首先是函數參數壓棧順序,其次是壓入堆棧的內容由誰來清除,調用者還是函數自己?
              這些開關用來告訴編譯器產生什么樣的匯編代碼。
            (2)VC有兩種函數調用方式   一種是__stdcall,另一種是__cdecl  
             函數的調用方式有兩種一種是PASCAL調用方式(_stdcall),另一種是C調用方式(_cdecl)  
             使用PASCAL調用方式,函數在返回到調用者之前將參數從棧中刪除  
             使用C調用方式,參數的刪除是調用者完成的  
             WinMain函數是由系統調用的,Windows系統規定由系統調用的函數都遵守PASCAL調用方式  
             但是VC中函數的缺省調用方式是__cdecl,也就是C調用方式  
             所以在WinMain前顯示的聲明。  
             在Windows編程中將遇到很多聲明修飾符,如CALLBACK,WINAPI,PASCAL這些在Intel CPU的計算機上都是__stdcall
            (3)__cdecl是C/C++和MFC程序默認使用的調用約定,也可以在函數聲明時加上__cdecl關鍵字來手工指定。采用__cdecl約定時,
             函數參數按照從右到左的順序入棧,并且由調用函數者把參數彈出棧以清理堆棧。
             因此,實現可變參數的函數只能使用該調用約定。
             由于每一個使用__cdecl約定的函數都要包含清理堆棧的代碼,所以產生的可執行文件大小會比較大。
             __cdecl可以寫成_cdecl。
             __stdcall調用約定用于調用Win32 API函數。采用__stdcal約定時,函數參數按照從右到左的順序入棧,被調用的函數在返回前清理傳送參數的棧,
             函數參數個數固定。由于函數體本身知道傳進來的參數個數,因此被調用的函數可以在返回前用一條ret n指令直接清理傳遞參數的堆棧。
             __stdcall可以寫成_stdcall。
             __fastcall約定用于對性能要求非常高的場合。__fastcall約定將函數的從左邊開始的兩個大小不大于
             4個字節(DWORD)的參數分別放在ECX和EDX寄存器,其余的參數仍舊自右向左壓棧傳送,被調用的函數在返回前清理傳送
             參數的堆棧。
             __fastcall可以寫成_fastcall。
            (4)thiscall僅僅應用于“C++”成員函數。this指針存放于CX/ECX寄存器中,參數從右到左壓。thiscall不是關鍵詞,因此不能被程序員指定。
            (5)naked call。當采用其他的調用約定時,如果必要的話,進入函數時編譯器會產生代碼來保存ESI,EDI,EBX,EBP寄存器,
             退出函數時則產生代碼恢復這些寄存器的內容。

            ·特別說明
            1. 在默認情況下,采用__cdecl方式,因此可以省略.
            2. WINAPI一般用于修飾動態鏈接庫中導出函數
            3. CALLBACK僅用于修飾回調函數
            4. 你可能已經發現,VC下和BCB下對WINAPI的定義不同,那么你至少理解了
               為什么不能直接從BCB下調用VC的dll的一個原因了。
              
            不查不知道,一查嚇一跳,怎么那么多規則的?整理了一下思路,其實并不復雜。
            VC默認的是_cdecl方式,Win32 API函數是用_stdcall方式的,他們都是將函數參數從右到左入棧的。
            _cdecl方式的每個函數都有清理堆棧的代碼,可以實現可變參數列表,但可執行文件大小比較大。_stdcall方式是調用者清理堆棧的。
            _fastcall的特點是它將參數左邊的兩個參數放在寄存器上,比較快。其余參數還是在堆棧中,堆棧還是由函數自己清除。
            其它就不太清楚了。

            好,該看看函數的參數了,hInstance是當前應用程序實例的Handle.
            第二個參數hPrevInstance應用程序上一個實例的Handle。MSDN說:如果你要知道應用程序是否有另一個實例,建議使用Mutex(互斥體)來實現。此時,我想到了
            單例模式,用Mutex來實現只運行一個實例。
            第三個參數lpCmdLine是一個字符串,是命令行參數。
            第四個參數nCmdShow是一個int,指明Window應該怎么現實,Windows定義了一系列宏,來幫助記憶,以SW開頭,如:SW_SHOW

            最后是返回值,它是一個int。
            MSDN說:If the function succeeds, terminating when it receives a WM_QUIT message, it should return the exit value contained in that message's wParam parameter. If the function terminates before entering the message loop, it should return zero.
            如果它成功的話,它會一直運行,知道收到WM_QUIT消息,它應該返回消息的wParam參數的退出值。如果函數在進入消息循環前退出,它應該返回0。
             

            posted on 2009-05-31 09:15 wil 閱讀(1638) 評論(2)  編輯 收藏 引用 所屬分類: Windows APIs

            評論

            # 您的博客背景看著好累呀 2009-11-01 23:29 baihonghong

            您博客背景好傷眼睛呀,為什么不用點柔和一些的顏色呢  回復  更多評論   

            # re: Windows API(1) WinMain函數 2010-03-18 10:56 apple

            太厲害了,感覺自己還連入門都沒有啊。  回復  更多評論   

            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            導航

            統計

            常用鏈接

            留言簿(1)

            隨筆分類

            隨筆檔案

            文章分類

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            久久久精品视频免费观看| 青青青国产成人久久111网站| 久久免费国产精品| 中文精品久久久久人妻不卡| 久久人人爽人人爽人人AV东京热| 香蕉久久一区二区不卡无毒影院| 武侠古典久久婷婷狼人伊人| 三上悠亚久久精品| 欧美与黑人午夜性猛交久久久| 国色天香久久久久久久小说| 国产午夜福利精品久久| 影音先锋女人AV鲁色资源网久久| 国产精品久久久福利| 久久只有这精品99| 久久―日本道色综合久久| 无码国内精品久久综合88| 女人香蕉久久**毛片精品| 亚洲av日韩精品久久久久久a | 久久本道久久综合伊人| 色综合久久综合中文综合网| 欧美无乱码久久久免费午夜一区二区三区中文字幕 | 91精品国产91久久综合| 亚洲国产成人精品无码久久久久久综合| 亚洲精品乱码久久久久久按摩| 国产亚州精品女人久久久久久 | 久久亚洲AV成人无码国产| 亚洲Av无码国产情品久久| 国产精品青草久久久久福利99 | 午夜欧美精品久久久久久久 | 亚洲AV无一区二区三区久久| 久久久久久久91精品免费观看| 很黄很污的网站久久mimi色 | 久久久久免费精品国产| 99久久婷婷国产综合亚洲| 久久狠狠高潮亚洲精品| 久久婷婷五月综合色奶水99啪| 国产精品亚洲综合久久| 久久久久亚洲AV片无码下载蜜桃 | 久久天天躁狠狠躁夜夜avapp| 久久香综合精品久久伊人| 久久久久人妻一区二区三区 |