Leaderboard

Suggesting you support an OS you don't at least test once is not a good idea. I have a Windows 7 VM that has Delphi 6 to XE installed, and I build and run stuff with a few of those compilers occasionally, so I know it still works. Trying to support anything older is dangerous. That VM still gets some Windows security updates, so has minimal support from Microsoft. One common API to avoid for Windows 7 is GetTickCount64 which was added with Vista and Windows 2008, don't think Delphi uses it internally. Angus

Timestamping happens on the client - just like with signtool, you specify the timestamp server url and digest algorithm - we caclulate the file digest, send that to the server, get back the signed digest/signature etc, apply that the the file and then perform the timestamp operation (simplified - quite a bit to it in reality). This is the command line interface (subject to change) We are using Signotaur to sign itself, here's an extract from the build log - running the sign command "C:\Program Files\VSoft Technologies\Signotaur\ClientTool\SignotaurTool.exe" sign --apikey ********** --thumbprint 56DFCD0B0C37DD1B9AB75FFCAB6627745E6E93B6 --signServer https://ciagent005:91 --file-digest SHA384 --tr http://timestamp.digicert.com --td SHA256 --allow-untrusted E:\CI_AWS\Ws\18154\Output\**\*.exe" and the output (logging needs some tuning). SignotaurClient Version : 1.0.0.182 © 2024 VSoft Technologies Pty Ltd 12:19:33 Fetching public key 12:19:33 Sending sign request to server... 12:19:36 Server responded : "Digest Signed OK" 12:19:36 "E:\CI_AWS\Ws\18154\Output\Client\win-x64\SignotaurTool.exe" signed. 12:19:36 Sending sign request to server... 12:19:38 Server responded : "Digest Signed OK" 12:19:39 "E:\CI_AWS\Ws\18154\Output\Server\win-x64\VSoft.Signotaur.Server.exe" signed. 12:19:39 Sending sign request to server... 12:19:41 Server responded : "Digest Signed OK" 12:19:41 "E:\CI_AWS\Ws\18154\Output\Server\win-x64\VSoft.SSLCertificate.Tool.exe" signed. 12:19:41 Returning result code: 0. 12:19:41 Result from Windows signing API "Operation successful." Exit code: 0 So signing and timestamping takes around 1-3 seconds per file (depends on file size etc).

What is the goal here? GetTickCount64() is available in Vista (6.0) onward. The page you quoted says the 64bit tick counter existed in 5.1, but wasn't actually in use until 5.2. So 5.2->6.0 is a pretty small window if you are just looking to emulate GetTickCount64() on pre-Vista systems.

Also third party components could in theory use some API not only VCL.

The required Windows version really depends on the the VCL features you use. If you're using something that is only available in Windows 10 then naturally your application will use Windows 10 specific APIs. Otherwise it will not.

Maybe these lists are intersting too, although not 1:1 what you're asking for: https://github.com/ideasawakened/DelphiKB/wiki/Delphi-Master-Release-List https://en.wikipedia.org/wiki/History_of_Delphi_(software)

We'll look at this. I haven't seen any api's to make this easy, so will likely have to resort to manipulating the PE file. That said, if you sign without using the -as option I think it will replace the existing certificate - I will have to test that. We are planning on adding a timestamp command but that is not yet implemented (mostly because we haven't gotten to it yet). Should be simple to add - I had it in there originally but couldn't figure out why it would be needed - signtool doco doesn't say much We went around in circles with this, we needed something unique to identify the certificate - IssuedTo/SubjectName is not unique if more than one token is enabled (ie old cert and new cert). I'll talk to the lead dev about this when he is back from vacation next week - I did the initial r&d and then handed the project off to another dev to make it into a product and this is one of the areas he worked on. Thanks for the feedback.

In XE2 and later, for reasons of backward compatibility I guess, you can get away with not using fully qualified unit scope names for the RTL/VCL etc if you add the required prefixes to project options (Delphi Compiler section, Unit scope names field). Certain default prefixes are added by Delphi when you create a new project. For a new VCL application in Delphi 12.2 I get: Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;System;Xml;Data;Datasnap;Web;Soap;Vcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell That's probably why the "mixed" code works, but it's asking for trouble IMHO. I worry about possible conflicts using default unit scope names, so I usually delete all the default prefixes from project options, which enforces the use of fully qualified scope names. In library code that needs to compile with compilers either side of XE2, where it can't be guaranteed that the user will have any default unit scopes defined, I use something like: {$UNDEF RequiresUnitScopeNames} {$IFDEF CONDITIONALEXPRESSIONS} {$IF CompilerVersion >= 24.0} // Delphi XE3 and later {$LEGACYIFEND ON} // NOTE: this must come before all $IFEND directives {$IFEND} {$IF CompilerVersion >= 23.0} // Delphi XE2 and later {$DEFINE RequiresUnitScopeNames} {$IFEND} {$ENDIF} then in uses statements, for e.g.: uses {$IFNDEF RequiresUnitScopeNames} Windows, Classes; {$ELSE} Winapi.Windows, System.Classes; {$ENDIF} It's a pain, and it's easy to forget to add both versions of a unit name, but it works for me. BTW the $LEGACYIFEND stuff is a work around for problems I encountered with the way $IFEND and $ENDIF work in XE3 and later! Your mileage may vary.

They are called Unit Scope Names, not qualifiers. And don't confuse them with Namespaces, which uses a similar naming syntax but different semantics. Here is a useful site: List of Delphi Pascal Features and When Introduced

We're working on a code signing server that supports tokens/pfx etc - allows you to do remote code signing very easily. All you need is network access to the server from a remote location (ideally over a vpn) and the client (a command line tool, which FinalBuilder will support). We're just tidying up loose ends (like the installer) before beta - hopefully in a few weeks.

I also don't understand why they create this kind of darkness... unless it is for the reasons like those above... I see Emba like a dark cathedral, with many corners, and people are walking in there quietly and with candles in their hands. It is all full of candle smoke. From time to time somebody is quietly coughing and the others are looking bad at him. The windows are covered with black drapes. Outside in the sun, the children are playing. They are happy now, but the know at one time, night will come and maybe the people in the cathedral will save them. C# is upon us.. C# is upon us.... C# is upon us.......

Delphi shows the first form that is created as the main form. Check your project options, you might have to change the order of forms.