Kas Ob.

Great and perfect and Thank you !

Right, i should have mentioned that may be as i read that second source you linked. According to this i have the it should (might) work for all starting from Windows XP SP2/SP3 and Server 2003 SP1, and that include 32Bit and 64Bit , as shown per declaration with 64bit size in that link, It is the same declared in DDK headers https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/ns-ntddk-kuser_shared_data also here explain the size of KSYSTEM_TIME https://osm.hpi.de/wrk/2007/08/getting-os-information-the-kuser_shared_data-structure/ And there a confession to make there is a condition i omitted in the code because i don't see it as big relevant, in 64bit there is a loop to establish that High2Time and High3Time are identical, this happen if updating one was happening at this very exact moment, i tried to slow my CPU by overloading up to 100%, and couldn't make this trigger, then tried to downclock and overclock CPU, as mine is Intel unlocked (model with "k"), yet even over more than an hour and in both cases could capture such case not even once, and i am not saying it is right to capture it, but i am saying statistically i satisfied, also even when they are not identical, meaning the result will be as much as it was like 100ns before, so no harm there, this can affect and important for kernel drivers, but can not be critical for any software in user mode.

Well, not exactly, QueryPerformanceCounter does have higher resolution but with lower accuracy, it is tied to the CPU cycles, at that low level, yes it has very high resolution, but when the CPU throttle or switch power profile it will start to return far from accurate result, also will be far from accurate in hibernate, GetTickCount on other hand depends or gets its clock timing using BIOS clock interrupt which in turn gets its time from the MotherBoard chipset, this one doesn't suffer from power profile effect, these chipset runs at constant frequency and they are very accurate but with lower precision than the CPU, due to their difference in base frequencies (CPU and motherboard chipset).

I opened a thread about GetTickCount, that safely replace this GetTickCount64, but will wait until confirmation of success result as explained there, before suggesting to replace any short coming of GetTickCount64 this with that direct (emulated) version.

On side note: I never saw "/ph" and "/nph" being used, and honestly don't know what exactly they do, only can imagine or assume, If you have any resources on this, i would appreciate sharing !

Nice ! Few thoughts : 1) Albeit there is no mention for Remove/Delete a signature in Microsoft documentation in three different places for SignTool https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/signtool https://learn.microsoft.com/en-us/dotnet/framework/tools/signtool-exe https://learn.microsoft.com/en-us/windows/win32/seccrypto/signtool The command "remove" is useful and pretty needed, sometimes it is essential, example, you want to switch form internal debugging/testing signature to release, and don't want to ship with your organization internally issued signatures and its certificate, so remove/delete is needed, and it is there within SignTool.exe, i remember have seen in the documentation in the past ! 2) With SignTool there is "/ac" option for the Sign command, this one can be crucial for new CA certificates, as best practice dictate to include the chain of trust path excluding the root, root must not be included as it will be considered waste and manipulation (root should be presented and trusted by different source like OS store or any higher/adequate administrative authority), but CAs between end point and root can be the line between verification and failure, including the chain of trust is essential for old systems and/or new CAs, so you might need to consider to add it. 3) Identifying or choose the certificate by thumbprint is OK, but i would suggest to use similar method like SignTool and IIS, by adding "IssuedTo/SubjectName", this will minimize the hustle of update thumbprint on client/terminal side when more than 1 certificate do exist, as they will exist, like generally you order new certificate while the soon to expired still there, if you look at IIS, it always select the newer certificate after filtering the available certificates with Subject Alternative Name match the domain name, same for sign tool does the same by "/n" option and looking for the SubjectName, so adding this also make sense. Well, this comes to mind and thank you again !

Yes not for everyone, yet the decentralization and distribution of the signature log might help or at least increase the chance of avoiding catastrophic failure or again at least faster response, in case of compromise did happen, some might look and see logs with different colors of the names and/or the time of multi signature happened at 3AM then you go why and what Andres had signed binaries, could his station being hijacked !, lets notify him or the responsible person. Anyway, food for thought, and this what i did and my clients loved it !

Then i would expand on this and suggest to make like what i did, on every sing issued the result on both GUI and console client side, it does grab last few signing operation and disclose them to every one is singing, as the best security is transparency and awareness, this means any singing developer can have a glance of what have being signed last 5-10 singing procedures, with time, dates, authorization and the binary name. Just food for thoughts. And thank you very much !

@Vincent Parrett Feature suggestion even before seeing this great tool As i already did 3 projects for 3 different clients, although it wasn't for USB or hardware tokens, but for usual certificate and its private key, the project was to keep the private key securely stored away from developers machines, yet monitor what executables were signed and by whom, stored IPs and devs authentication in detailed nice logs, also the administrator could allow only the digest to be shipped to the server but also allow the administrator to choose who can not sign without uploading the whole binary to be stored on the server for .. security and trust reasons. My suggestion is to expand or at least consider the forced operation logging on server side, this is not something belongs to best practice and i am sure it will be requested sooner or later.

Name suggestion if you interested : "DSign" or "DSigning" from Distributed .. ihm... i meant Delphi . The latter yield zero search result on both DDG and Google.

Yes they have reasons, and this 100% doesn't include solving your mentioned problem, these APIs are about locking/reserving physical memory, to one end and one reason, minimizing page faults for one critical application, hence recover or reserve performance as much as possible, and by performance i mean the just to prevent losing performance due to high memory usage and paging to file, and that is it. I can't imagine how this can help your application not crashing, but i can few scenarios where it delay the crash enough that you don't notice, this does not fix the problem, and there is bug(s) somewhere, it might be 1) Your bug very similar to the @dummzeuch mentioned, it is coming from casting pointer to signed integer then perform some operations on that integer, like shuffling it to other variables, or do some arithmetic operation with it, back in days 32bit application had 2GB and there wasn't a problem, i mean there wasn't crashing or access violations (because the problem is there waiting), then comes the boot switch /3GB that allowed/added one extra GB to the memory rendering all the abusing of the pointer as access violation, but this didn't happen or noticed right away as it will happen arbitrary, and only when your application utilized so much memory, in newer Windows version, the OS started to make this allocation addresses more arbitrary, hence these bugs started to show even if your application didn't utilize a lot of memory, anyways, these access violation and miss use of pointers, could be easily found and fixed by use the FastMM4 with MEM_TOP_DOWN, which i remember is default, hence will fixed right away, without you might depend on luck and high memory usage to capture. 2) Your application in fact using high volume of memory but it does abuse threading and miss using timing, if you have one Sleep because you are assuming an operation will take 5ms and you gave it something like 500ms, that should be fine, right ? NO ! , you are wrongly assuming this can be enough, because when when paging hit, the operation will block, by operation i mean a single CPU instruction will trigger OS VMM intervention due to hard page fault, and this thread will block until VMM free some physical memory, not really free (!!) but stop another thread/process and then write its memory from the physical to the page file, then load you paged memory, then continue your thread, by continue i mean literally re-execute that single instruction, the one stopped the earth planet form rotation. These bugs coming from miss using timing where very frequent back in days with HDD, with SSD it is faster and wrong logic might pass unchallenged, yet with heavy software running on OS like Windows Defender that literally capable to utilize the disk operation at tens of thousands operations per second when it does scan, these bugs come to light again. So i hope that was readable and clear, and of course i hope helps identifying your bugs, but one thing is for sure denying physical memory by manipulating working set, is not good sign at all, let your application be free of bugs and let it take small extra time due paging, and let the OS perform as intended.

The listed errors are linker ones, which means there is a confliction in the compiled source units, to understand these errors you have to get in the shoes of the compiler and linker, the compiler check for the source file time for last modification and build the .o/.obj (same goes for the .dcu in Delphi), (well dates and times among other parameters but most relevant is the time) if these times are identical then will skip compiling !!, assuming it is the same and nothing changed then nothing to recompile, linker on other hand will build the executable binary from scratch and from its own build version, here comes the unresolved externals... in case the .o/.obj files were built/compiled with different compiler form different IDE. Delphi doesn't suffer form this because DCU files has the compiler version included (again among others, like all the compiling switches are there in the DCU) , while .o/.obj files can't be used effectively as dcu files. So it is either bug in the compiler where it should check for the compiler version (and project switches) before skip compiling, Or you have to clean your paths from all artefacts (.o , .obj...) to be able to build on different compiler, I can't say for sure about this being compiler bug or not.

At +5 pixel, most likely you are resizing the form from the corner, try to increase this, or pick a point where no resizing might happen, +10 do it , like this SimulateMouseDrag(left+10, top+10, left+200, top+200);

Should be {$SETPEFLAGS IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP or IMAGE_FILE_LARGE_ADDRESS_AWARE} You missed an "or" !

What happen if Windows Service called "Theme" is stopped and disabled ? Will the flicking continue to exist with RDP ?

I wouldn't expect much on/from this, for many years i am not fan of what Embarcadero focusing their effort and resources, but about this particular one, i don't think they can do much. Take an example CFG, it is still new and not fully matured by Microsoft itself, while the real deal (the devil most needed) in its parts is RFG, this one in particular is not standardized and i really don't expect they will have any specification any time soon if ever ! Without written specification, no compiler and linker can perform/produce compliant code, a code that OS require to to perform undocumented behavior while still changing on the OS part, so ... Embarcadero can't help or do much for now, yet there is parts can be implemented, here i am talking about parts to be comply with the known and documented part of the CFG. The request for RFG is outrageous and out of the reality as you mentioned it, even Rust with LLVM can't do it. I expect that audit is more like the more the merrier in a (longer) list of checkboxes without thinking them enough, and it is their right to do so after all, they should everything they can think of, the red line is were to make it a deal breaker. On this i agree, this is Embarcadero lack or lag in this space, they neglected this part for very long time, i mentioned 2 DLLs out of punch i came across and you have one, i had in few projects to remove the import for these two DLLs to raise a project rank in VirusTotal, signed or not signed was it. But for Embarcadero to do something about this they need put effort and ask for what should be removed or adjusted, the community can report them, of course some public awareness is critical here, so an initiative should be take a place, started by Embarcadero. I am out of touch with the new IDEs, and really don't know if the mentioned above DLLs still relevant now, but many here aware about this now and can help, as for FireMonkey and cross platforms.

Other than checking the Edition, i would do compile an empty unit and check for the artefact or the output, though i never installed or used CE, so might be wrong about this approach, but the fact it is not exiting with ExitCode=1 is disturbing non the less D:\Program Files (x86)\Embarcadero\Studio\16.0\bin>dcc32 EmptyUnit.pas Embarcadero Delphi for Win32 compiler version 29.0 Copyright (c) 1983,2015 Embarcadero Technologies, Inc. EmptyUnit.pas(8) 9 lines, 0.02 seconds, 15 bytes code, 4 bytes data. unit EmptyUnit; interface implementation end.

May be the approach is very similar between CnWizard Editor Enhancement and newer IDEs, adjusting the gutter after seeing the need to, combine this with very busy system at this moment to cause some delay in update. Anyways, i was just pointing that this behavior or visual effect is/was there with older IDEs.

I witness this in both Delphi 2010 and XE8 almost always, this visible more in XE8 and when the Editor open a big file for the first time, it adjust the gutter on them all, if the editor has a file with more than 10k line it will be most noticeable. BUT, 100% sure this artefact from CnPack/CnWizard in my case.

If you have capital Latin letters then just subtract 64. In case of small Latin letters then subtract 96. https://en.wikipedia.org/wiki/ASCII

I have no idea why this DLL is imported, but searching landed me here https://learn.microsoft.com/en-us/windows/win32/api/avrt/ And those belongs to https://learn.microsoft.com/en-us/windows/win32/procthread/multimedia-class-scheduler-service Nothing more about this, except some little rant about how Delphi RTL and VCL using and importing stuff just because the original designer didn't think it through, useless stuff, like every single Delphi application is importing winspool.drv for no reason at all except the idea that every application should use the printer !! and historically the Printer Drivers were the most abused for security vulnerabilities, hence just adding more stuff to irritate any AV about Delphi applications, also there is this one "winsta.dll" which as i recall were used as backup in case the application can't figure the OS version, so there is a static import for this DLL and it is not call, this DLL is the library responsible for many terminal and servers (stations) connection and licenses managing, communicating... etc , this one is red flag for any application in the eyes of any Security software (AV)... enough of that. I think you can't do any of these in Delphi except this one "Authenticode", which has nothing to do with the compiler or linker, this is not even a flag, this is the Digital Signature as defined by Microsoft, so all you have to pass this, is to sign you binaries with Code Signing Certificate issued by trusted Certificate Authority that leads to trusted root in the OS store (certificate store). The rest names decryption : cfg = Code Flow Guard , Delphi compiler can't produce compatible code for this, in fact i don't any other compiler than VS will do it, as the whole CFG is not yet matured, and really should depend on specific hardware, namely CPU features, this is new standard. to read more about this https://www.intel.com/content/dam/develop/external/us/en/documents/catc17-introduction-intel-cet-844137.pdf forceIntegrity = https://learn.microsoft.com/en-us/cpp/build/reference/integritycheck-require-signature-check?view=msvc-170 well this one is complete useless and will not add any security what so ever, easy to enable though as it is a simple bit in the PE header gs = well this one is tricky as it might be Gs or GS https://learn.microsoft.com/en-us/cpp/build/reference/gs-buffer-security-check?view=msvc-170 https://learn.microsoft.com/en-us/cpp/build/reference/gs-control-stack-checking-calls?view=msvc-170 One does need special stack protection explained by stack cookies while the other ensure free buffer zone in the stack, both Delphi can't do ! rfg = Return Flow Guard very similar to CFG, also to my knowledge this one is part of CFG, and it is useless to make it out of CFG, and there is no specification yet on how to be implemented except in theory and as VS do it ! https://security.stackexchange.com/questions/206560/methods-of-exploiting-a-windows-executable-protected-by-control-flow-guard-and I hope that explained the whole thing a little for you, also the one who compiled the report for you, adding these together may be didn't understand them fully or what do they means or how they works, it could be one of these great software that do understand security and how it should be implemented (/sarcasm/), in all cases CFG and GS are impossible with Delphi compiler and linker, although GS protection is possible by using EurekaLog, but it will kill the performance of you application, yet they can not see the flag where the OS will do its part, so the protection against the stack/buffer overflow will be there but no one will witness, audit report should be based on actual source and deep understand what it does, yet it might be regulatory thing these days. as for CFG and its RFG, if it is that much needed then you need to redo you application in VS (namely Visual Studio) nothing else. Good luck and hope that was clear.

This made laugh and angry at the same time, along with audit in the same post. Anyways, don't have time, to write a lot, but later will post about this and give you some rest. Meanwhile, convert and build your application to Visual Studio from a company called Microsoft to pass these flags, which are not named as they should.

This warning/error is here forever, i suggest to do yourself a favor and rewrite the above with future proof parameters.

No issue there, just simple error.

Well see ROT13, Caesar and their family, these doesn't need key but easy to add one in case you want to, by shifting (adding) by the key, these it might fit your need Start here https://stackoverflow.com/questions/6800326/how-to-crypt-or-hide-a-string-in-delphi-exe A nice playground for Cesar https://www.dcode.fr/caesar-cipher And in general https://www.dcode.fr/en Also https://www.dcode.fr/vigenere-cipher looks nice and does have a key https://en.wikipedia.org/wiki/Vigenère_cipher Yet from quick look at it, i think it might fit your need more than Cesar or ROT13, might be wrong though, In all cases i hope this will give you at least start point for your search, and of course i believe many here will give you insight too.