64位只有一种调用约定stdcall

procedure TForm2.Button1Click(Sender: TObject);
function EnumWindowsProc(Ahwnd: hwnd; AlParam: lParam): Boolean; stdcall;
begin
ShowMessage(‘hwnd:‘ + IntToStr(Ahwnd));
ShowMessage(‘lParam‘ + IntToStr(AlParam));
Result := True;
end;

begin
EnumChildWindows(0, @EnumWindowsProc, 123);
end;
代码就是上面这点,选择编译32位平台,123会被传送到LParam里,选择编译64位平台123会被传送到hwnd里,这是怎么回事?
IDE是XE6,是我不会用吗?
----------------------------------------------

function EnumWindowsProc(Ahwnd: hwnd; AlParam: lParam): Boolean; stdcall;
begin
ShowMessage(‘hwnd:‘ + IntToStr(Ahwnd));
ShowMessage(‘lParam‘ + IntToStr(AlParam));
Result := True;
end;

procedure TForm2.Button1Click(Sender: TObject);
begin
EnumChildWindows(0, @EnumWindowsProc, 123);
end;

这样既可.
因为你如果要用嵌套函数的话编译出来的和外边的函数是不同的.
嵌套函数编译后编译器会多给一个参数作为第一个参数.这个参数保存的是父函数的栈底.当父函数调用这个嵌套函数的时候32位会塞ebp,64位会塞rbp作为第一个参数进来.

之所以32位表现似乎是没问题,因为你是stdcall,32位的时候是用栈传递参数,那么当
EnumChildWindows调用到你的函数时,你的函数取的是栈顶的三个值,刚好后两个就是Ahwnd,AlParam.

而64位只有一种调用约定stdcall,而stdcall的参数是rcx,rdx,r8,r9传递前四个参数,后面用栈传.EnumChildWindows调用你的函数的时候只给了rcx,rdx两个值.而你的函数则认为应该是rcx,rdx,r8三个参数.那么你的123被EnumChildWindows当成第二个参数放在rdx中.而你的回调函数则认为自己有三个参数,rcx是编译器给的父函数的栈底,rdx是Ahwnd.

基本就是上面的情况.
----------------------

时间: 2024-12-25 22:12:44

64位只有一种调用约定stdcall的相关文章

在win64里,只有一种调用约定

在win64里,只有一种调用约定.以下是通过寄存器来传递4个整数类型的例子: *RCX:第一个参数 *RDX:第二个参数 *R8:第三个参数 *R9:第四个参数 参数里开头的4个整数会这样传给栈.传递浮点数参数时,使用的是XMMO-XMM3寄存器. 调用约定简化了:一律使用__fastcall,前四个参数用 RCX.RDX.R8 和 R9传递,除了这四个外加RAX.R10.R11,其他寄存器都是非易失的.

宏WINAPI和几种调用约定

在VC SDK的WinDef.h中,宏WINAPI被定义为__stdcall,这是C语言中一种调用约定,常用的还有__cdecl和__fastcall.这些调用约定会对我们的代码产生什么样的影响?让我们逐个分析. 首先,在x86平台上,用VC编译这样一段代码: 1 int __cdecl TestC(int n0, int n1, int n2, int n3, int n4, int n5) 2 { 3 int n = n0 + n1 + n2 + n3 + n4 + n5; 4 return

windows 10(64位)下实现vs20120C++调用matlab r2014a编写的m文件生成的.dll,.lib,.h文件

如题. 环境:windows10 64位,vs 2010,matlab r2014a,配置成功,生成.dll,.h,.lib文件成功. 步骤一:matlab动态链接库文件编译生成 1)编写示例文件add.m function c = add(a, b); c = a + b; end; 2)编译打包 进入matlab主界面,在控制台输入deploytool命令,调用打包程序,选择"Library Compiler": 3)进入库文件编译程序界面,根据需要勾选C++ Shared Lib

关于32位和64位部署出现C#调用delphi动态库DLL不成功的问题

由于项目中调用了动态库,这些动态库放在C:\Windows\System32下面,但是当部署到了64位的机器上可能就有问题了,最近这个问题就纠结了半天,在本机32为系统上测试动态调用ddl成功了,部署到64位Window Server2008上面也没问题,可是为什么到了64位的WIN7系统上出了问题呢?        最后才发现原来原来是DLL的位置不对,那么DLL到底该放到那呢?        如果细心的你,你会发现在C:\Windows\目录下面有两个文件夹:System目录和System3

3种调用约定的区别与联系

由C代码到汇编代码来看看cdecl.stdcall.fastcall三个调用约定的区别: int __stdcall add1(int x,int y) { return x + y; } int __cdecl add2(int x, int y) { return x + y; } int __fastcall add3(int x, int y,int z) { return x + y +z; } int _tmain(int argc, _TCHAR* argv[]) { add1(1

几种调用约定

调用约定(Callingconvention)决定以下内容:函数参数的压栈顺序,由调用者还是被调用者把参数弹出栈,以及产生函数修饰名的方法.MFC支持以下调用约定: 1._cdecl 按从右至左的顺序压参数入栈,由调用者把参数弹出栈.对于"C"函数或者变量,修饰名是在函数名前加下划线.对于"C++"函数,有所不同. 如函数voidtest(void)的修饰名是_test:对于不属于一个类的"C++"全局函数,修饰名是[email protecte

64位进程调用32位dll的解决方法 / 程序64位化带来的问题和思考

最近做在Windows XP X64,VS2005环境下做32位程序编译为64位程序的工作,遇到了一些64位编程中可能遇到的问题:如内联汇编(解决方法改为C/C++代码),long类型的变化,最关键的遇到了64位进程需要调用32位dll的问题.由于有一些32位dll没有源代码,无法重新编译为64位dll,所以只能想办法解决64位进程调用32位dll问题,这个问题让我很是挠头了几天. 相关资料:微软公司的官方网站针对这个问题描述如下:在64位的windows系统中,一个64位进程不能加载一个32位

32位程序注入64位DLL到64位进程

向其它进程注入DLL通常的做法是通过调用CreateRemoteThread这个API在目标进程内创建一个远程线程.用这个线程来调用LoadLibraryA或LoadLibraryW(下文统称LoadLibrary)以实现让目标进程载入指定的DLL文件. 使用CreateRemoteThread创建一个远程线程须要传入一个线程过程函数的地址,而且这个函数地址是须要在目标进程中有效的. 因为LoadLibrary是kernel32.dll的导出函数.所以对于执行在同一个系统上的同为32位的进程或同

x86 x64下调用约定浅析

x86平台下调用约定 我们都知道x86平台下常用的有三种调用约定,__cdecl.__stdcall.__fastcall.我们分别对这三种调用约定进行分析. __cdecl __cdecl是C/C++的默认调用约定,如果不显示声明调用约定的情况下,就是该调用约定.下面我们来从汇编层次来熟悉这种调用约定. 我写了一个函数,如下: 1 int __cdecl TestCdecl(int a, int b, int c, int d, int e) 2 { 3 return a + b + c +