为什么不能将地址转换为64位Delphi中的嵌套本地函数?

时间:2012-04-15 14:09:44

标签: delphi delegates nested delphi-xe2 32bit-64bit

AS。关闭相关问题 - 下面添加更多示例。

以下简单代码(找到顶级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, 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;
    TypedEnumChildWindows(Wnd, @EnumChildren, UINT_PTR(@WndChild));

    if WndChild <> 0 then
      ..

end;

实际上,此限制并非特定于Windows API回调,但将该函数的地址转换为procedural type的变量并将其作为自定义比较器传递给{{1}时会发生同样的问题。 }}

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

TList.Sort

在编译为32位时,它按预期工作,但在为Win64编译时失败并带有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; 。对于函数Access Violation中的64位版本,compares = nil =某个随机值;

如果在i2函数之外提取compare函数,它也可以按预期工作,即使对于Win64目标也是如此。

1 个答案:

答案 0 :(得分:20)

这个技巧从来没有得到语言的正式支持,而且由于32位编译器的实现细节,你迄今为止一直在使用它。 documentation很清楚:

  

嵌套过程和函数(在其他例程中声明的例程)不能用作过程值。

如果我没记错的话,一个额外的隐藏参数会被传递给嵌套函数,并带有指向封闭堆栈帧的指针。如果没有引用封闭环境,则在32位代码中省略。在64位代码中,额外的参数总是被传递。

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

无论如何,最重要的是你不能将嵌套函数作为参数传递给64位编译器中的另一个函数。