Une application Delphi de bureau peut-elle être certifiée pour Windows 8 (à l'aide du kit de certification Windows App) ?

Question

Apparemment, Delphi (toute version) ne prend pas en charge les gestionnaires d'exception sûrs (commutateur /SAFESEH dans Visual Studio). Cela entraîne un avertissement lors de l'utilisation de Windows Desktop App Certification Kit sur Windows 8. Par exigences de certification pour les applications de bureau Windows 8 :

Votre application doit être compilée en utilisant le drapeau /SafeSEH pour garantir une gestion sûre des exceptions.

Il est évident que Delphi ne dispose pas de ce commutateur, ce qui rend la chose impossible. Mes questions sont les suivantes :

1. Si j'ai bien compris, même si le kit n'affiche qu'un avertissement (et non un échec), étant donné qu'il s'agit d'une exigence "obligatoire", toute application Delphi actuelle ne peut pas être certifiée pour Windows 8 et ne peut donc pas être incluse dans le magasin d'applications Windows ?

2. Les tables SafeSEH peuvent-elles être ajoutées à un fichier PE après la compilation d'une manière ou d'une autre (par exemple en extrayant les informations nécessaires du fichier map ou des symboles de débogage), ou avons-nous absolument besoin du support d'un compilateur/lien pour cela, et devons-nous donc attendre qu'Embarcadero implémente cette fonctionnalité ?

Pour clarifier, mon application est une application de bureau Windows 32 bits (compatible 64 bits), pas d'application Metro .

Answer 1

Je ne peux pas répondre à la question 1. Cependant, je trouve difficile d'imaginer que l'utilisation du mot doit pourrait signifier que la règle est facultative.

Pour ce qui est de la question 2, vous aurez besoin de l'aide du compilateur/lien. Vous ne pouvez pas raisonnablement vous attendre à ce qu'un outil de post-linking d'édition PE vienne à bout de ce problème. Considérez le code suivant :

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

Le compilateur émet le message suivant :

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);
........

Maintenant, le vrai gestionnaire d'exception est HandleOnException mis en œuvre dans System.pas . Mais, l'adresse poussée sur la pile est $0041c3c9 une adresse locale du code contenant le try/except bloc. Cela signifie qu'afin de créer une section PE SafeSEH, vous devez localiser chaque try/except dans votre code. Bien que cela soit évidemment faisable, je ne pense pas que ce soit faisable.

Je m'imaginais plutôt que les gestionnaires d'exception SEH pour le compilateur x86 seraient juste le _HandleXXX les fonctions déclarées dans System.pas . Dans ce cas, il serait assez facile d'ajouter une section PE énumérant uniquement ces fonctions en tant qu'étape post-lien. Cependant, puisque chaque try/except a son propre gestionnaire d'exception local, je crois maintenant que seul l'auteur du compilateur peut espérer de façon réaliste ajouter la section SafeSEH PE.

Il n'y a, pour autant que je sache, aucun rapport de CQ qui demande SafeSEH le support du compilateur x86 de Windows. Je vous suggère d'enregistrer un rapport de contrôle de qualité et un cas de support officiel.

Mise à jour : Bravo à @haimg qui a réussi là où j'ai échoué et a réussi à trouver un rapport de contrôle de qualité : QC#106781 .

Answer 2

Il y a d'autres facteurs pour lesquels l'application pour Delphi ne peut être certifiée

http://delphitools.info/2012/08/23/why-no-native-winrt-support-in-delphi-xe3/