Vincent Parrett

Actually found some wintrust api's are in WinApi.Windows - fooled by code insight again 🙄 I really wish the windows api translations followed the original h files - a WinApi.Wintrust would make it much easier to find.

ntifs.h, wintrust.h - probably others - still working out what I need.

Yeah I'm making progress just using the windows api's - the most annoying part is not having delphi translations for much of what I need. I did see the mitec library - as you say it doesn't do writing. After spending much of the day searching/reading, I think I will just have to bite the bullet and do it from scratch.

Yeah I did have a quick look at it.. not what I need. I found plenty of code for reading the basic PE/MSDOS headers, but I need to get into the sections etc. I'm investigating adding certificates so need to enumerate sections and append some data to to the exe. So it's a lot more involved than just reading the basic info.

Thanks but not really - I need much more in depth than that.

You should also add the AssemblyIdentity and Description elements, but otherwise it should be ok. Edit : recommend you take a look at https://learn.microsoft.com/en-au/windows/win32/sbscs/application-manifests - it lists whether elements are required or not.

There is no specific guid for Windows 11 accorrding to MS "The following GUIDs correspond with the indicated operating systems: {8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a} -> Windows 10, Windows 11, Windows Server 2016, Windows Server 2019 and Windows Server 2022"

You might also want to add high dpi support via the dpiAware or dpiAwareness elements

The reason for the Ctrl A issues is because the manifest file controls what version of the common controls your application uses - without it you get the very old versions. FinalBuilder uses the manifest file you specifiy in the Delphi Action. No, use the example in the blog post that @Uwe Raabe linked to - it's actually the manifest we use for FinalBuilder. The blog post also details why you should not use the one generated by the IDE. In fact FinalBuilder cannot use the delphi IDE generated manifest file for two reasons The ide never saves the file anywhere but in the projectname.res file (annoyingly - since this is source code). It uses a template file that uses variables only available to the delphi IDE.

I didn't use Berlin (I did try but had too many issues) - went from XE7 to 10.4.2 (failed again due to issues) - and then 11.x - 11.3 is not perfect but it's usable. My project is a few exe's and around 100 packages (32bit vcl) - around 4M lines of code. IDE using 600MB, LSP 400MB. I have not run into any out of memory issues with 11.3 - I have had issues with code insight occasionally stops working, but found my old trick of closing the project, deleting the .identcache seems to get it working again. Like every release in the last 10 years, the debugger isn't great but is usable for the most part - the 64bit debugger is pretty flakey (along with the compiler) - so for now I'm sticking to 32bit. YMMV.

Well that's a first 😅

I'm sure we would all love to see a 64bit IDE, but emb have limited resources, and right now they need to focus on more important issues.

I certianly hope they do not migrate the IDE to 64bit anytime soon - the 64bit compiler is no where near as good as the 32bit compiler (speed, code generation) - and switching to 32bit would switch around the debugging experience 32bit IDE 32 bit debugging - not great 64 bit debugging - awful 64bit IDE 32 bit debugging - awful 64 bit debugging - not great Careful what you wish for.

I came across this interesting comparison yesterday between Goroutines and C# async/await (part of a group of articles comparing the languages). https://alexyakunin.medium.com/go-vs-c-part-1-goroutines-vs-async-await-ac909c651c11 Well worth a read. TLDR - Goroutines are faster, easier to use than async await (async everywhere is a pain), stack sizes matter and Go runs out of memory long before C# - in the benchmarks at least.

Something that has helped for me with previous versions is to delete any .identcache files in your source folders before opening the project. I thought that was a thing of the past... but 11.3 codeinsight etc stopped working for me today in 11.3 (only showing templates in the dropdown) and doing that brought it back to life again.

@Malcolm will be able to answer this.

Which was is a PITA as it makes inc files just a tad more complicated than they would be otherwise. I usually have something like this so I can have one inc file that supports versions before and after XE4 {$IF CompilerVersion > 24.0 } //XE4 or later {$LEGACYIFEND ON} {$IFEND}

Agreed, guilty as charged. I've been modifying the inc files in my projects over the last few days.. mostly so they will be compatible with D12 without me having to do anything when it's released (unless they introduce breaking changes). I too prefer packages for each compiler versions - I have had too many issues over the years with the IDE messing up package upgrades and then not being able to compile - usually fixed by deleting the dproj and creating a new one.

I would say no. It's not hard to guess what the next compiler version will be. However, publishing packages saved with that beta may well be an NDA violation.

Received my new OV token from Digicert today - it is a SafeNet 5110+ FIPS token (thankfully) and I am able to automate signing with it 😅 I spent some time messing with a self signed certificate on a yubikey token over the last week, but cannot for the life of me figure out how to get it to sign without prompting for a password. This was just an experiment with the yubikey (which I already had for other purposes).

I ended up purchasing an 3yr OV certificate (EV seems like a waste to me) from GoGetSSL.com which was substantially cheaper (USD$730 including $120 shipping - better come wrapped in a vault!) than anywhere else - turns out they are owned by digicert and once you order you they create an account for you on Digicert and the request process is done on the digicert site.

I also bought a yubikey to test with self signed certificates - but haven't found a way to automate signing without the password prompt (bought it just to research this).

I have received so much conflicting infomation from the CA's (much like their terrible websites) - codesigningstore.com (sslstore.com) sent this in response to my enquiry So if they send me a Safenet token, all good, but if I buy a sectigo cert and want to renew using the same token in 3 yrs time - I cannot? I'm seeing similar vague/ambiguous responses from other sellers. I have asked for clarification, but none so far.

In the original RFC it was proposed that qualification of a device had to be done by an independant qualified person - but I am seeing CA's list which devices they will support. Unfortunatley that changes over time so the token I have is no longer usable. Looks interesting, although Digicert's are the most expensive certificates you can buy, eye watering prices for small business to absorb.

It's certainly at odds with the notion that we should automate things so they work correctly every time. I for one am not going to sit there typing a pin and pushing a button for every file that I sign. If I cannot automate, then I will either not sign at all, or sign with a self signed certificate and provide the public key on my website for customers to install (to avoid the invalid certificate error). Of course microsoft, who has a big hand in this push to hardware storage of certificates, just happens to own a whole bunch of HSM's (azure key vault) and it working on a code signing service for azure - which they would like us all to use eventually - for a fee.