Posted by jpluimers on 2021/04/21
I totally missed this, even though the file has been around for a very long time:
–jeroen
Posted in Delphi, Development, DUnit, Software Development | Leave a Comment »
Posted by jpluimers on 2021/04/20
Some links on rebase for Windows DLLs and EXE files, including effects on .NET CLR.
In the presence of ASLR, rebasing your DLLs has no effect because ASLR is going to ignore your base address anyway and relocate the DLL into a location of its pseudo-random choosing.
Mind you, even though rebasing has no effect, it doesn’t hurt either.
If you are on a system without ASLR (either because it predates ASLR, or because ASLR has been disabled for whatever reason), then rebasing will help, for the traditional reasons.
Mind you, systems without ASLR are really hard to find nowadays, so rebasing provides no benefit in the overwhelming majority of cases. But in that vanishingly small percentage of cases where you don’t have ASLR, then rebasing helps.
Conclusion: It doesn’t hurt to rebase, just in case, but understand that the payoff will be extremely rare. Build your DLL with
/DYNAMICBASEenabled (and with/HIGHENTROPYVAfor good measure) and let ASLR do the work of ensuring that no base address collision occurs. That will cover pretty much all of the real-world scenarios. If you happen to fall into one of the very rare cases where ASLR is not available, then your program will still work. It just may run a little slower due to the relocation penalty.
–jeroen
Posted in .NET, Delphi, Development, Software Development, Windows Development | Leave a Comment »
Posted by jpluimers on 2021/04/20
A while ago, I discovered that most (if not all) Delphi compiled Windows binaries contain the PLATFORMTARGETS resource.
This is a resource introduced in Delphi XE2 meant to be included in package binaries only.
The documentation back then clearly indicates this:
Relatively recent documentation too: [WayBack] 64-bit Windows Application Development – RAD Studio: Making Your Components Available at Design Time and Run Time
Still all my Delphi compiled binaries contain the PLATFORMTARGETS resource.
When did the compiler behaviour change to include PLATFORMTARGETS in ALL binaries?
–jeroen
Posted in Delphi, Development, Software Development | Leave a Comment »
Posted by jpluimers on 2021/04/15
From a while ago, but still very relevant:
twitter.com/search?q=%23Spring4D&src=typd
Posted in Delphi, Development, Software Development | Leave a Comment »
Posted by jpluimers on 2021/04/14
It took me a file to figure out another cause for “F2063 Could not compile used unit“, this was for a 3rd party library that had parts of the units as source files, but other parts as DCU files.
The offending unit only had DCU files, and those were in the path.
It finally occurred to me that I had a project having a DCU for the wrong Delphi version in the path.
That version check is easy to do: the 4th byte of a unit contains the CompilerVersion value with which the DCU file was compiled, and should be used with:
The first entry is for CompilerVersion value 31 (for hexadecimal value $1F) which corresponds with Delphi 10.2 Tokyo.
The last last is for CompilerVersion value 32 (for hexadecimal value $20) which corresponds with Delphi 10.3 Rio.
All versions are in Delphi version info table: C# Builder, Delphi 8 through 10.3 Rio and Appbuilder.
Related:
On the DCU and TPU file formats:
–jeroen
Posted in Delphi, Development, Software Development | Leave a Comment »
Posted by jpluimers on 2021/04/13
Just so I remember this did not compile in Delphi XE8 a while ago:
[dcc32 Fatal Error] DisableAlignPropertyEditor.dpr(15): E2213 Bad packaged unit format: c:\program files (x86)\embarcadero\studio\16.0\lib\Win32\release\rtl.dcp.System.SysUtils - Expected version: 29.0, Windows Unicode(x86) Found version: 32.0, Windows Ansi(x86)
Possible starting point: “E2213 Bad packaged unit format” “Expected version” “Found version” “Windows Unicode” “Windows Ansi” – Google Search
–jeroen
Posted in Delphi, Delphi XE8, Development, Software Development | Leave a Comment »
Posted by jpluimers on 2021/04/08
Interesting idea by Cesar Romero (who has some interesting repositories at [WayBack] cesarliws (Cesar Romero) · GitHub and [WayBack] cesarliws — Bitbucket) when using TestInsight for Delphi: first test if TestInsight is running at all: [WayBack] foundation-4-delphi/Foundation.Test.Utils.pas at master · cesarliws/foundation-4-delphi · GitHub.
function IsTestInsightRunning: Boolean; {$IFDEF TESTINSIGHT} var TestInsightClient: ITestInsightClient; begin TestInsightClient := TTestInsightRestClient.Create; TestInsightClient.StartedTesting(0); Result := not TestInsightClient.HasError; end; {$ELSE} begin Result := False; end; {$ENDIF} procedure RunRegisteredTests; begin ReportMemoryLeaksOnShutdown := True; {$IFDEF TESTINSIGHT} if IsTestInsightRunning then TestInsight.DUnit.RunRegisteredTests else {$ENDIF} DUnitTestRunner.RunRegisteredTests; end;
Another interesting bit from the same library is the deferer pattern (which is different from the promise pattern!) in [WayBack] foundation-4-delphi/Foundation.System.pas at master · cesarliws/foundation-4-delphi · GitHub with the below code examples.
I think a better name might be DeferExecutionToEndOfScopeFor.
procedure ProcessFile (const FileName: string); var File: TFile; begin File: = TFile.Open (FileName); Defer (File.Close); while not File.EOF begin // ... process file end; end; // Defer will be executed here [File.Close] procedure ExecSql (const ConnectionString, Sql: string); var Database: TDatabase; Exec: IDeferred; Query: TQuery; begin Database: = TDatabase.Create (ConnectionString); Exec: = Defer (Database.Free); Database.Open; Exec.Defer (Database.Close); Query: = Database.Query (SQL); Exec.Defer (Query.Free); Exec.Defer (Query.Close); if Query.IsEmpty then Exit; while not Query.EOF begin // ... process query end; Exec.Defer ( procedure begin Writeln ('Finished ExecSql'); end ); end; // Defer will be executed here [Writeln, Query.Close, Database.Close, Database.Free]
–jeroen
Posted in Delphi, Development, Software Development, Spring4D, TestInsight | Leave a Comment »
Posted by jpluimers on 2021/04/07
From a check-in a while ago, when some Delphi versions complained about CallerAddr having been replaced by ReturnAddress and other versions not understanding ReturnAddress, but having CallerAddr.
The code in the [WayBack] gist and on [WayBack] BitBucket:
ReturnAddressUnitto provideReturnAddressto Delphi versions not supporting it, and preventCallerAddrwarnings for Delphi versions havingReturnAddress. See https://bitbucket.org/jeroenp/wiert.me/src/…/Native/Delphi/Library/RTL/ReturnAddressUnit.pas
Basically the code maps a variable having a variable ReturnAddress that is a function reference returning a pointer to a function and redirects to CallerAddr when there is no ReturnAddress available. This is the case for anything below Delphi XE2, and avoids W1000 Symbol 'CallerAddr' is deprecated: 'Use ReturnAddress' for Delphi XE2 and up
It is an extract from [WayBack] dunit-extension/TestCaseExtension.pas at master · fabriciocolombo/dunit-extension · GitHub.
There is more interesting code in [WayBack] GitHub – fabriciocolombo/dunit-extension: Extended DUnit TestCase provides assertions to the types Date, Enumerator, Double, and other types, and a class to help run tests with output as XML, text and GUI mode and even more in [WayBack] fabriciocolombo (Fabricio Colombo) · GitHub , which are on my list of things to play with in the future.
Some more [WayBack] commits are at [WayBack] GitHub – cesarliws/dunit-extension (more on [WayBack] Cesar Romero tomorrow).
I think the code from Fabricio is inspired by [WayBack] ZeosLib/TestFrameWork.pas at master · svn2github/ZeosLib · GitHub as it uses the same HAS_BUILTIN_RETURNADDRESS define.
The code by Fabricio is smarter though.
Via: “Delphi” “CallerAddr” “ReturnAddress” – Google Search
–jeroen
Posted in Delphi, Development, DUnit, Software Development | Leave a Comment »
Posted by jpluimers on 2021/04/06
Last week, I wrote about msbuild verbosity levels. The post was both for my own documentation, but also out of need as I wanted to have way more verbose logging for a Delphi build process involving search path configurations.
When using my Delphi build script you can both pass msbuild options and Delphi compiler options:
Run-Dependend-rsvars-From-Path.bat 5 msbuild -verbosity:detailed "/p:DCC_OutputDependencies=true" MyProject.dproj
The bold one is the msbuild parameter, the italic one the Delphi compiler parameter for unit dependencies. They are directly passed to msbuild:
...\msbuild.exe /target:build /p:DCC_BuildAllUnits=true /p:config=Debug -verbosity:detailed "/p:DCC_OutputDependencies=true" MyProject.dproj
You can multiple options too:
Run-Dependend-rsvars-From-Path.bat 5 msbuild -verbosity:detailed "/p:DCC_OutputDependencies=true" "/p:DCC_Quiet=false" MyProject.dproj
In addition to unit dependencies, you can also get an overview of .dfm and other resource file dependencies by passing /p:DCC_OutputDRCFile=true on the command-line this will generate a DRC file that not just has all the resource string constants in it, but also a comment section specifying all resource files including these file types:
.dfm (form files).drf (which seems to be a temporary file having to do with package reference dependencies: [WayBack] What is a DRF file? Why is there a problem creating it?, [WayBack] packages – Delphi “E2161 Error: RLINK32: Error opening file ________.drf ” during Build All – Stack Overflow).res (resource files)Both DCC_OutputDependencies and DCC_OutputDRCFile can also be set to true in a .dproj file and are configurable under two different project option paths:
DCC_OutputDependencies: “Project Options” -> “Delphi Compiler” -> “Compiling” -> “Output unit dependency information”DCC_OutputDRCFile: “Project Options” -> “” -> “Delphi Compiler” -> “Linking” -> “Ouput resource string .drc file”The -verbosity:detailed however, is not passed to the various Delphi DCC compilers, as somewhere along the line, the CodeGear.Delphi.Targets got changed to Quiet="true" somewhere in-between Delphi 2007 and Delphi 2010.
Delphi 2007 had from
Borland.Delphi.Targetsfiles containing fromQuiet="$(DCC_Quiet)"; the file got renamed and changes likely in Delphi 2009. See these related posts:
- [WayBack] QualityCentral 56289: MSBuild does not pass the quiet option to DCC32
- [WayBack] delphi – Is there a way to turn off the quiet mode in DCC32 called by MSBuild? – Stack Overflow
- [WayBack] How can I get MSBuild to do a full build of a Delphi project equivalent to dcc32 -b? – Stack Overflow
- [WayBack] 2018-03-31 – twm’s blog: Specifying the msbuild configuration for a Delphi project on the commandline
- [WayBack] What are the MSBuild project level properties for Delphi? – Stack Overflow
- [WayBack] Delphi MSBuild Build Configurations From Command Line – Stack Overflow
- [WayBack] Command line build questions : MSBUILD console output is either wickedly verbose (compiling delphi .dprojs) or completely off. – delphi
This means as of then on, the DCC commandline compilers will always output non-verbose logging. Even specifying "/p:DCC_AdditionalSwitches=-Q-" will not help: you will just get blank lines.
In the past, one of the things the verbose DCC logging would help you to see which files where accessed using the actual build. This was a tremendous help when figuring out search path problems that kick in every now and then.
For units, there is a little trick you can use here: it’s the /p:DCC_OutputDependencies=true" option you see above.
It will output an additional file with the .d extension that:
That file is relatively easy to scan or parse for path problems.
I am not sure at which Delphi version the depends feature became a project setting, but it is. The odd thing: it does not always work, at least not in the Delphi 102. Tokyo installations I have used.
In a .dproj file, it is inside this element: <DCC_OutputDependencies>true</DCC_OutputDependencies> just like the msbuild name.
In the UI, you can find it here:
DCC_AdditionalSwitches and /p:DCC_AdditionalSwitches
msbuild %1 /t:Build /p:config=%2 /p:DCC_AdditionalSwitches="-W^"
and
msbuild %1 /t:Build /p:config=%2 /p:DCC_Warnings=error="-W^"
DCC_OutputDependencies and and p:/DCC_OutputDependencies
–jeroen
Posted in Continuous Integration, Delphi, Development, msbuild, Software Development | Leave a Comment »
Posted by jpluimers on 2021/04/06
If you want to run both DUnitX and DUnit tests in a test project using TestInsight as runner encapsulation, then you need to be aware that when there are no DUnitX tests, it will raise an exception.
So use this code to prevent that:
try TestInsight.DUnitX.RunRegisteredTests; finally TestInsight.DUnit.RunRegisteredTests; end;
–jeroen
Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »
The Wiert Corner - irregular stream of stuff 