桌面Delphi应用程序是否可以针对Windows 8进行认证（使用Windows应用程序认证工具包）？

显然，Delphi（任何版本）（VisualStudio中的/SAFESEH开关）。在Windows 8上使用Windows桌面应用程序认证工具包时，这会导致警告。适用于Windows 8桌面应用程序的每：

您的应用程序必须使用/SafeSEH标志编译，以确保安全的异常处理

显然，Delphi缺少此开关，因此无法执行此操作。我的问题是：

我的理解正确吗？即使工具包只显示一条警告（不能失败），因为这是“必须”的要求，现在任何Delphi应用程序都不能通过Windows 8认证，因此不能包含在Windows应用商店中

是否可以在编译后以某种方式将SafeSEH表添加到PE文件中（例如，从映射文件或调试符号中提取所需信息），或者我们绝对需要编译器/链接器支持，因此必须等到Embarcadero实现此功能

---

为了澄清，我的应用程序是Windows 32位桌面应用程序（64位兼容），而不是Metro应用程序。

我无法回答问题1。然而，我发现很难想象“必须”一词的使用可能意味着该规则是可选的

至于问题2，您需要编译器/链接器的支持。您不能合理地期望使用PE编辑帖子链接工具对此进行调整。考虑下面的代码：

try
  Beep;
except
  on E: Exception do
    Writeln(E.ClassName, ': ', E.Message);
end;

编译器发出以下消息：

Project1.dpr.11: try
0041C3AA 33C0             xor eax,eax
0041C3AC 55               push ebp
0041C3AD 68C9C34100       push $0041c3c9 // exception handler is at $0041c3c9
0041C3B2 64FF30           push dword ptr fs:[eax]
0041C3B5 648920           mov fs:[eax],esp
Project1.dpr.12: Beep;
0041C3B8 6A00             push $00
0041C3BA E8E1CEFEFF       call MessageBeep
0041C3BF 33C0             xor eax,eax
0041C3C1 5A               pop edx
0041C3C2 59               pop ecx
0041C3C3 59               pop ecx
0041C3C4 648910           mov fs:[eax],edx
0041C3C7 EB59             jmp $0041c422
0041C3C9 E97291FEFF       jmp @HandleOnException
0041C3CE 0100             add [eax],eax
0041C3D0 0000             add [eax],al
0041C3D2 E42F             in al,$2f
0041C3D4 41               inc ecx
0041C3D5 00DA             add dl,bl
0041C3D7 C3               ret 
0041C3D8 41               inc ecx
0041C3D9 00A3D83E4200     add [ebx+$00423ed8],ah
Project1.dpr.15: Writeln(E.ClassName, ': ', E.Message);
........

现在，真正的异常处理程序是

HandleOnException

，在

System.pas

中实现。但是，推送到堆栈上的地址是

$0041c3c9

，这是包含

try/except

块的代码的本地地址。这意味着，为了创建SafeSEH PE节，您需要找到代码中的每个

try/except

。虽然这显然是可行的，但我认为这是不容易处理的

我认为x86编译器的SEH异常处理程序只是

\u HandleXXX

在

System.pas

中声明的函数。在这种情况下，添加一个只列出这些函数的PE部分作为post链接步骤是很容易的。然而，由于每个

try/except

都有自己的本地异常处理程序，我现在相信只有编译器作者才能真正希望添加SafeSEH PE部分

据我所知，没有任何QC报告要求对x86 Windows编译器提供

SafeSEH

支持。我建议您记录一份QC报告和一份官方支持案例

---

更新：对@haimg做得很好，因为我在失败的地方取得了成功，并设法找到了一份质量控制报告：。

德尔福应用程序无法认证还有其他因素

---

您可以修改PE文件以添加safeseh部分。但这需要大量的私募股权投资。我认为Delphi SEH异常处理程序是System.pas中的_Handle***函数。但我不确定尝试这样做有多明智。有人做过质量控制报告吗？你提出了支持的理由了吗？令人惊讶的是，在QC中搜索SafeSEH却没有结果。在有人记录质量控制报告之前，什么能促使Emba采取行动。请不要就此止步。打开一个支持案例，这样你就可以与Emba内部的真人交谈。这样你就有机会得到反馈。@David，“Emba”已经开始运作了。这种支持很可能会在下一个版本的Delphi中发布，这将是第一个支持Win8的版本。对于一个在一年前编译器发布时还没有正式上架的操作系统，很难向编译器/IDE添加“官方支持”。EMBT对有关Win8的问题的回答目前“不受官方支持”，正是出于这个原因。@Ken SafeSEH是在XP service pack中引入的。@Ken如果在下一个Delphi发布时完成重写，我会非常惊讶。如果dcc32立即被淘汰，我会非常惊讶。我希望移交工作更为进步。但如果有人想让SafeSEH发生，他们应该让Emba知道。只是咕噜咕噜没用，谢谢。实际上，有一个QC请求（尽管它处于“需要更多信息”阶段）：很好地找到了。我使用了基于网络的QC搜索，没有得到任何点击。无论如何，我还是建议你记录一个支持案例。至少你会得到一些迹象表明Emba是否意识到这一点，是否正在进行研究，何时发布等等。我不是在说WinRT，很明显，我们不能用Delphi针对WinRT。我说的是常规的x86 WinAPI Delphi应用程序，它们在Windows 8上运行正常，但无法通过认证，因为Delphi中缺少一些编译器功能。噢，很抱歉误解了