Can a desktop Delphi application be certified for Windows 8 (using Windows App Certification Kit)?
Asked Answered
S

2

29

Apparently, Delphi (any version) does not support safe exception handlers (/SAFESEH switch in Visual Studio). This results in a warning when using Windows Desktop App Certification Kit on Windows 8. Per certification requirements for Windows 8 desktop apps:

Your app must be compiled using the /SafeSEH flag to ensure safe exceptions handling

Obviously Delphi lacks this switch, so it cannot be done. My questions are:

  1. Is my understanding correct, that even though the Kit displays only a warning (not fail), since this is a "must" requirement, any Delphi app today cannot be certified for Windows 8 and therefore cannot be included in the Windows app store?

  2. Can SafeSEH tables be added to a PE file after the compilation somehow (e.g. extracting needed info from the map file or debug symbols), or we absolutely need a compiler/linker support for this, and therefore must wait till Embarcadero implements this feature?

To clearify, my application is Windows 32-bit desktop application (64-bit compatible), not Metro application.

Snowinsummer answered 31/7, 2012 at 5:45 Comment(8)
You may well be able to modify the PE file to add the safeseh section. But it will require a deal of PE hacking. The Delphi SEH exception handlers are, I think, the _Handle*** functions in System.pas. I'm not sure how wise it would be to try to do this though. Has anyone made a QC report yet? Have you lodged a support case yet?Stearn
Rather amazingly a search for SafeSEH in QC yields no results. Until somebody logs a QC report, what's going to prompy Emba into action. And please don't just stop there. Open a support case so that you can talk to real people inside Emba. That way you have a chance of getting feedback.Stearn
@David, "Emba" is already in action. The support will most likely be released in the next version of Delphi, which will be the first one to support Win8. It's hard to add "official support" to a compiler/IDE for an OS that hasn't officially hit the shelves yet when the compiler was released nearly a year ago. The EMBT response to questions about Win8 is currently "not officially supported" for that very reason.Influential
@Ken SafeSEH was introduced in an XP service pack.Stearn
@David, "introduced" <> "required for certification". And the compiler is in the middle of a major rewrite now.Influential
@Ken Well whatever, but there seem to be a number of people wanting SafeSEH and it's more likely to happen with a QC report and the lodging of a support case. I'm not sure about the relevance of the re-write. I'm not aware that the 32 bit Windows compiler (the only one for whom SafeSEH applies) is being re-written for the next release of Delphi.Stearn
@David, my understanding is that the entire compiler backend is being rewritten. There are threads about it (the rewrite, not SafeSEH) in the EMBT forums (non-technical and language, IIRC). I seem to recall some discussion about SafeSEH and C++ Builder, too, but I don't recall for sure. Perhaps Remy Lebeau will stop by - he's TeamB/C++ Builder, so he may know more about that topic.Influential
@Ken I'd be very surprised if that re-write was completed by the time the next Delphi was released. And I'd be very surprised if dcc32 was phased out immediately. I expect a more progressive hand-over. But if anyone wants SafeSEH to happen, they should let Emba know. It's no good just gurning about it on SO.Stearn
S
3

I cannot answer question 1. However, I find it hard to imagine that the use of the word must could mean that the rule was optional.

As for question 2, you would need support from the compiler/linker. You cannot reasonably expect to back fit this with a PE editing post-link tool. Consider the following code:

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

The compiler emits the following:

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

Now, the real exception handler is HandleOnException, implemented in System.pas. But, the address pushed onto the stack is $0041c3c9, an address local to the code containing the try/except block. This means that in order to create a SafeSEH PE section you would need to locate each and every try/except in your code. Whilst that is obviously feasible, I don't think it is tractable.

I rather imagined that the SEH exception handlers for the x86 compiler would be just the _HandleXXX functions declared in System.pas. In which case it would be easy enough to add a PE section listing just those functions as a post-link step. However, since every single try/except has its own local exception handler, I now believe that only the compiler author can realistically hope to add the SafeSEH PE section.

There is, so far as I can see, no QC report that requests SafeSEH support for the x86 Windows compiler. I suggest that you log a QC report, and an official support case.

Update: Well done to @haimg for succeeding where I failed and managing to locate a QC report: QC#106781.

Stearn answered 31/7, 2012 at 13:23 Comment(2)
Thanks. There is, actually, a QC request (although it's sitting in "need more info" stage): qc.embarcadero.com/wc/qcmain.aspx?d=106781Snowinsummer
Well done for finding that. I used the web based QC search and got no hits. Anyway, I still suggest that you log a support case. At the very least you'll get some indication whether or not Emba are aware of this, are working on it, when it might be released etc. etc.Stearn
A
0

There are other factors why the application for Delphi can not be certified

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

Administer answered 26/12, 2012 at 15:14 Comment(2)
I'm not talking about WinRT, that's obvious that we cannot target WinRT with Delphi. I'm talking about regular x86 WinAPI Delphi applications, that run ok on Windows 8 but cannot be certified because a couple of compiler features are missing from Delphi.Snowinsummer
Oh, sorry for the misunderstandingAdminister

© 2022 - 2024 — McMap. All rights reserved.