delphi - 为什么不能在 64 位 Delphi 中获取嵌套局部函数的地址？

Question

作为。自关闭相关问题以来 - 下面添加了更多示例。

下面的简单代码(查找顶级 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 回调，但是当将该函数的地址放入过程类型的变量并将其传递(例如，作为自定义比较器)时，会发生同样的问题到TList.Sort。

http://docwiki.embarcadero.com/RADStudio/Rio/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 时，会因访问冲突而失败。对于 64 位版本的函数 compare，s = nil 和 i2 = 某个随机值；

如果在 btn1Click 函数之外提取 compare 函数，即使对于 Win64 目标，它也能按预期工作。

Answer 1

这个技巧从未得到该语言的正式支持，并且由于 32 位编译器的实现细节，迄今为止您一直在逃避它。 documentation很清楚:

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

如果我没记错的话，一个额外的隐藏参数将通过指向封闭堆栈帧的指针传递给嵌套函数。如果未引用封闭环境，则在 32 位代码中将省略此内容。在 64 位代码中，总是会传递额外的参数。

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

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