为什么不能在64位Delphi中使用地址嵌套本地函数?

前端之家收集整理的这篇文章主要介绍了为什么不能在64位Delphi中使用地址嵌套本地函数?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
如.关闭相关问题 – 下面添加更多例子.

以下简单的代码(找到一个顶级的Ie窗口并枚举它的孩子)可以使用’32位Windows‘目标平台工作.早期版本的Delphi也没有问题:

procedure TForm1.Button1Click(Sender: TObject);

  function EnumChildren(hwnd: HWND; lParam: LPARAM): BOOL; stdcall;
  const
    Server = 'Internet Explorer_Server';
  var
    ClassName: array[0..24] of Char;
  begin
    Assert(IsWindow(hwnd));            // <- Assertion fails with 64-bit
    GetClassName(hwnd,ClassName,Length(ClassName));
    Result := ClassName <> Server;
    if not Result then
      PUINT_PTR(lParam)^ := hwnd;
  end;

var
  Wnd,WndChild: HWND;
begin
  Wnd := FindWindow('IEFrame',nil); // top level IE
  if Wnd <> 0 then begin
    WndChild := 0;
    EnumChildWindows(Wnd,@EnumChildren,UINT_PTR(@WndChild));

    if WndChild <> 0 then
      ..    

end;

我插入了一个Assert来指示它在64位Windows目标平台上失败的位置.如果我解嵌回调,代码就没有问题.

我不知道使用参数传递的错误值是否只是垃圾,还是由于一些错误的内存地址(调用约定?).嵌套回调是什么,我不应该首先做的事情?还是这只是我要忍受的缺陷?

编辑:
响应David的答案,与EnumChildWindows相同的代码用一个类型的回调声明.工作正常32位:
(编辑:下面没有真正测试大卫说的话,因为我仍然使用’@’运算符,它与运算符工作正常,但如果我删除它,它确实不会编译,除非我解嵌回调)

type
  TFNEnumChild = function(hwnd: HWND; lParam: LPARAM): Bool; stdcall;

function TypedEnumChildWindows(hWndParent: HWND; lpEnumFunc: TFNEnumChild;
    lParam: LPARAM): BOOL; stdcall; external user32 name 'EnumChildWindows';

procedure TForm1.Button1Click(Sender: TObject);

  function EnumChildren(hwnd: HWND; lParam: LPARAM): BOOL; stdcall;
  const
    Server = 'Internet Explorer_Server';
  var
    ClassName: array[0..24] of Char;
  begin
    Assert(IsWindow(hwnd));            // <- Assertion fails with 64-bit
    GetClassName(hwnd,nil); // top level IE
  if Wnd <> 0 then begin
    WndChild := 0;
    TypedEnumChildWindows(Wnd,UINT_PTR(@WndChild));

    if WndChild <> 0 then
      ..

end;

实际上这个限制并不是特定于Windows API回调的,但是当将该函数的地址变成过程类型的变量并将其传递给TList.Sort作为自定义比较器时,会发生同样的问题.

http://docwiki.embarcadero.com/RADStudio/XE4/en/Procedural_Types

procedure TForm2.btn1Click(Sender: TObject);
var s : TStringList;

  function compare(s : TStringList; i1,i2 : integer) : integer;
  begin
    result := CompareText(s[i1],s[i2]);
  end;

begin
  s := TStringList.Create;
  try
    s.add('s1');
    s.add('s2');
    s.add('s3');
    s.CustomSort(@compare);
  finally
    s.free;
  end;
end;

它按照预期的方式编译为32位,但在为Win64编译时失败了Access Violation.对于功能比较中的64位版本,s = nil和i2 =一些随机值;

如果在btn1Click函数之外提取比较函数,它也可以像Win64目标一样预期.

解决方法

这个技巧从来没有被语言支持,而且由于32位编译器的实现细节,你迄今为止已经把它截掉了. documentation是清楚的:

Nested procedures and functions (routines declared within other routines) cannot be used as procedural values.

如果我正确地记得,一个额外的,隐藏的参数传递给嵌套函数,指向包围堆栈帧的指针.如果没有引用封闭环境,则以32位代码省略.在64位代码中,额外的参数始终被传递.

当然,问题的一大部分是Windows单元使用无类型的过程类型作为其回调参数.如果使用了类型化的程序,编译器可以拒绝你的代码.事实上,我认为这是你所使用的技巧从来不合法的理由.使用类型回调,即使在32位编译器中也不能使用嵌套过程.

无论如何,底线是,您不能将嵌套函数作为参数传递给64位编译器中的另一个函数.

猜你在找的Delphi相关文章