Vincent Parrett

I'm looking for a library that will allow me to modifying windows PE file, modifying/adding data directories/headers/sections etc. Yes I could figure it all out myself, but time is short and I'm lazy, so I am hoping there is a library out there that will speed up the learning process - free/open source (not gpl) or commercial ok, as long as the source is available. Any suggestions? Thx.

Interesting, license is "as is" - so does that overrider the gpl of the other project - it doesn't appear to be any attribution of the original project - kinda disingenuous to misrepresent another's work as your own and then apply a GPL license to it 💁‍♂️

Yes thanks, I have seen this (and learned from it). I'm looking into building a remote signing tool - so that I can sign from multiple machines without needing the token drivers installed - right now we have to run all code signing on a single build agent that has access to the token - it's caused us a lot of work splitting out the code signing on all our build processes - which results in longer build times as we move files between agents and the server - ie agentX builds, sends artifacts back to server, server sends them to agent5 (the one that can sign), agent 5 signs them and sends them back to the server, which then sends them to agentX to continue the build process (pacakging and deployment etc). All very unsatisfactory. I haven't been able to work on it for a few weeks as other more urgent tasks popped up (like replacing confluence) but hope to get back to it soon.

Yes seems so, I saw that and decided against using it.

Thanks, hadn't seen this one.

Actually this is really useful - I've been working from some C based examples - I do actually need to add another section so this is is exactly what I need thanks.

I generally just set the major version on the manifest , e.g 8.0.0.0 and don't bother with updating it for every build. I also wouldn't use the Mage tool if you are not using .net - it adds stuff to the manifest you don't need/want.

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.