winmain()函数原型定义中,函数前的修饰符 winapi 的作用是什么呢?

kanzm 2008-12-21 11:07:30
winmain()函数原型定义中,函数前的修饰符 winapi 的作用是什么呢?
int WINAPI WinMain(
HINSTANCE hInstance, // handle to current instance
HINSTANCE hPrevInstance, // handle to previous instance
LPSTR lpCmdLine, // pointer to command line
int nCmdShow // show state of window
);

我查了下定义,好象winapi就是_stdcall,可是我不知这个_stdcall是什么意思?
请大家说说
...全文
654 6 打赏 收藏 转发到动态 举报
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
xqk 2008-12-24
  • 打赏
  • 举报
回复
_cdecl : 函数压栈方式从右到左,调用者主动恢复堆栈
PASCAL : 函数压栈方式从左到右,被调用者主动恢复堆栈,不支持变参
__stdcall : vc默认调用规则,函数压栈方式从右到左,被调用者主动恢复堆栈

以上是常见的函数调用规则
除此之外还有两种调用规则

__fastcall : 函数参数使用寄存器传递参数不够用再用堆栈传送 不同语言不同实现,使用2-4个通用寄存器一般,VC使用2个
__thiscall : 类成员函数使用该调用规则,与__stdcall调用规则相同,不同的地方在于命名用ECX传递this指针
xyhshen 2008-12-22
  • 打赏
  • 举报
回复
堆栈的使用方式
heidaizx 2008-12-22
  • 打赏
  • 举报
回复
学习了
kanzm 2008-12-22
  • 打赏
  • 举报
回复
#define WINAPI __stdcall
#define APIENTRY WINAPI
winapi已经是一个宏了,
可是第二句,
#define APIENTRY WINAPI
可以用一个宏定义另一个宏吗?有点不解
wqvbjhc 2008-12-21
  • 打赏
  • 举报
回复
别人的答案:
在windef.h头文件中有如下定义
#define WINAPI __stdcall
#define APIENTRY WINAPI

VC有两种函数调用方式 一种是__stdcall,另一种是__cdecl
函数的调用方式有两种一种是PASCAL调用方式,另一种是C调用方式
使用PASCAL调用方式,函数在返回到调用者之前将参数从栈中删除
使用C调用方式,参数的删除是调用者完成的
WinMain函数是由系统调用的,Windows系统规定由系统调用的函数都遵守PASCAL调用方式
但是VC中函数的缺省调用方式是__cdecl,也就是C调用方式
所以在WinMain前显示的声明。
在Windows编程中将遇到很多声明修饰符,如CALLBACK,WINAPI,PASCAL这些在IntelCPU的计算机上都是__stdcall
详细的声明细节请看windef.h文件
ilovedrv 2008-12-21
  • 打赏
  • 举报
回复
Visual C++中函数调用方式浅探
2003-11-3加入 来自未知 作者佚名 1条评论 点击1153次
我们知道在进行函数调用时,有几种调用方法,分为C式,Pascal式。在C和C++中C式调用是缺省的,除非特殊声明。二者是有区别的,下面我们用实例说明一下:

1. __cdecl :C和C++缺省调用方式
例子:
void Input( int &m,int &n);/*相当于void __cdecl Input(int &m,int &n);*/
以下是相应的汇编代码:
00401068 lea eax,[ebp-8] ;取[ebp-8]地址(ebp-8),存到eax
0040106B push eax ;然后压栈

0040106C lea ecx,[ebp-4] ;取[ebp-4]地址(ebp-4),存到ecx
0040106F push ecx ;然后压栈
00401070 call @ILT+5(Input) (0040100a);然后调用Input函数
00401075 add esp,8 ;恢复栈

从以上调用Input函数的过程可以看出:在调用此函数之前,首先压栈ebp-8,然后压栈ebp-4,然后调用函数Input,最后Input函数调用结束后,利用esp+8恢复栈。由此可见,在C语言调用中默认的函数修饰_cdecl,由主调用函数进行参数压栈并且恢复堆栈。

下面看一下:地址ebp-8和ebp-4是什么?
在VC的VIEW下选debug windows,然后选Registers,显示寄存器变量值,然后在选debug windows下面的Memory,输入ebp-8的值和ebp-4的值(或直接输入ebp-8和-4),看一下这两个地址实际存储的是什么值,实际上是变量 n 的地址(ebp-8),m的地址(ebp-4),由此可以看出:在主调用函数中进行实参的压栈并且顺序是从右到左。另外,由于实参是相应的变量的引用,也证明实际上引用传递的是变量的地址(类似指针)。
总结:在C或C++语言调用中默认的函数修饰_cdecl,由主调用函数进行参数压栈并且恢复堆栈,实参的压栈顺序是从右到左,最后由主调函数进行堆栈恢复。由于主调用函数管理堆栈,所以可以实现变参函数。另外,命名修饰方法是在函数前加一个下划线(_).

2. WINAPI (实际上就是PASCAL,CALLBACK,_stdcall)
例子:
void WINAPI Input( int &m,int &n);
看一下相应调用的汇编代码:
00401068 lea eax,[ebp-8]
0040106B push eax
0040106C lea ecx,[ebp-4]
0040106F push ecx
00401070 call @ILT+5(Input) (0040100a)
从以上调用Input函数的过程可以看出:在调用此函数之前,首先压栈ebp-8,然后压栈ebp-4,然后调用函数Input,在调用函数Input之后,没有相应的堆栈恢复工作(为其它的函数调用,所以我没有列出)

下面再列出Input函数本身的汇编代码:(实际此函数不大,但做汇编例子还是大了些,大家可以只看前和后,中间代码与此例子无关)

39: void WINAPI Input( int &m,int &n)
40: {
00401110 push ebp
00401111 mov ebp,esp
00401113 sub esp,48h
00401116 push ebx
00401117 push esi
00401118 push edi
00401119 lea edi,[ebp-48h]
0040111C mov ecx,12h
00401121 mov eax,0CCCCCCCCh
00401126 rep stos dword ptr [edi]

41: int s,i;
42:
43: while(1)
00401128 mov eax,1
0040112D test eax,eax
0040112F je Input+0C1h (004011d1)
44: {
45: printf("\nPlease input the first number m:");
00401135 push offset string "\nPlease input the first number m"... (004260b8)
0040113A call printf (00401530)
0040113F add esp,4
46: scanf("%d",&m);
00401142 mov ecx,dword ptr [ebp+8]
00401145 push ecx

00401146 push offset string "%d" (004260b4)
0040114B call scanf (004015f0)
00401150 add esp,8
47:
48: if ( m<1 ) continue;
00401153 mov edx,dword ptr [ebp+8]
00401156 cmp dword ptr [edx],1
00401159 jge Input+4Dh (0040115d)
0040115B jmp Input+18h (00401128)
49: printf("\nPlease input the first number n:");
0040115D push offset string "\nPlease input the first number n"... (0042608c)

00401162 call printf (00401530)
00401167 add esp,4
50: scanf("%d",&n);
0040116A mov eax,dword ptr [ebp+0Ch]
0040116D push eax
0040116E push offset string "%d" (004260b4)
00401173 call scanf (004015f0)
00401178 add esp,8
51:
52: if ( n<1 ) continue;
0040117B mov ecx,dword ptr [ebp+0Ch]
0040117E cmp dword ptr [ecx],1
00401181 jge Input+75h (00401185)
00401183 jmp Input+18h (00401128)

53:
54: for(i=1,s=0;i<=n;i++)
00401185 mov dword ptr [ebp-8],1
0040118C mov dword ptr [ebp-4],0
00401193 jmp Input+8Eh (0040119e)
00401195 mov edx,dword ptr [ebp-8]
00401198 add edx,1
0040119B mov dword ptr [ebp-8],edx
0040119E mov eax,dword ptr [ebp+0Ch]
004011A1 mov ecx,dword ptr [ebp-8]
004011A4 cmp ecx,dword ptr [eax]
004011A6 jg Input+0A3h (004011b3)

55: s=s+i;
004011A8 mov edx,dword ptr [ebp-4]
004011AB add edx,dword ptr [ebp-8]
004011AE mov dword ptr [ebp-4],edx
004011B1 jmp Input+85h (00401195)
56: if ( m >= s )
004011B3 mov eax,dword ptr [ebp+8]
004011B6 mov ecx,dword ptr [eax]
004011B8 cmp ecx,dword ptr [ebp-4]
004011BB jl Input+0AFh (004011bf)
57: break;
004011BD jmp Input+0C1h (004011d1)

58: else
59: printf(" m < n*(n+1)/2,Please input again!\n");
004011BF push offset string " m < n*(n+1)/2,Please input agai"... (00426060)
004011C4 call printf (00401530)
004011C9 add esp,4
60: }
004011CC jmp Input+18h (00401128)
61:
62: }
004011D1 pop edi
004011D2 pop esi
004011D3 pop ebx
004011D4 add esp,48h
004011D7 cmp ebp,esp
004011D9 call __chkesp (004015b0)

004011DE mov esp,ebp
004011E0 pop ebp
004011E1 ret 8
最后,我们看到在函数末尾部分,有ret 8,明显是恢复堆栈,由于在32位C++中,变量地址为4个字节(int也为4个字节),所以弹栈两个地址即8个字节。
由此可以看出:在主调用函数中负责压栈,在被调用函数中负责恢复堆栈。因此不能实现变参函数,因为被调函数不能事先知道弹栈数量,但在主调函数中是可以做到的,因为参数数量由主调函数确定。
下面再看一下,ebp-8和ebp-4这两个地址实际存储的是什么值,ebp-8地址存储的是n 的值,ebp -4存储的是m的值。说明也是从右到左压栈,进行参数传递。

总结:在主调用函数中负责压栈,在被调用函数中负责弹出堆栈中的参数,并且负责恢复堆栈。因此不能实现变参函数,参数传递是从右到左。另外,命名修饰方法是在函数前加一个下划线(_),在函数名后有符号(@),在@后面紧跟参数列表中的参数所占字节数(10进制),如:void Input(int &m,int &n),被修饰成:_Input@8
对于大多数api函数以及窗口消息处理函数皆用 CALLBACK ,所以调用前,主调函数会先压栈,然后api函数自己恢复堆栈。

如:
push edx
push edi
push eax

push ebx
call getdlgitemtexta
你可以想一下,这几个寄存器中存的都是什么?

参考:msdn
例子为在VC6.0下debug模式下的Win32 Console反汇编代码。

16,472

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧