The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,914 other followers

Archive for April 9th, 2019

Detecting the Delphi edition that is installed

Posted by jpluimers on 2019/04/09

Via [WayBack] In what ways can you detect which edition of Delphi in installed from the installed files? I’m trying to distinguish between Standard, Professional, E… – Jeroen Wiert Pluimers – Google+

Different Delphi editions have different msbuild support files. For instance IDL is only available in Enterprise/Architect/Ultimate (which use the exact same binaries anyway).

IDL is old, see

So I updated my [WayBack] jeroenp / / Run-Dependend-rsvars-From-Path.bat — Bitbucket (which besides running rsvars.bat, can start the various Delphi IDE personalities, or run msbuild with various configurations) with [WayBack] jeroenp / / commit / 2c55fa1bf786 — Bitbucket:

Support 10.1 Berlin and 10.2 Berlin in Run-Dependend-rsvars-From-Path.bat, as well as Professional/Starter editions.

Thanks to Andrea Magni – Google+, Querying was simple: look for the value of the Edition entry under inside the *\X\BDS\Y.0 where Y is the BDS version, X is Borland, CodeGear or Embarcadero (depending on the BDS version) and * is the base key HKEY_CURRENT_USER\Software, HKEY_LOCAL_MACHINE\SOFTWARE , HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node.


Posted in Delphi, Development, Software Development | Leave a Comment »

Continuous Integration Server performance

Posted by jpluimers on 2019/04/09

From a while back, but still relevant for any continuous integration system: [WayBack] Continuous Integration Server performance.


via: [WayBackBlogged – Continous Integration Server Performance – Vincent Parrett – Google+

Posted in Continua CI, Continuous Integration, Development, Software Development | Leave a Comment »

When generics and VCL controls bite you: memory overwrites when you show the control usually ending up in access violations

Posted by jpluimers on 2019/04/09

Recently I got bitten by the 2013 reported (too bad the site is gone and the WayBack machine doesn’t have it archived) as a result of [WayBackdelphi – Why do I get access violations when a control’s class name is very, very long? – Stack Overflow.

It got reentered as [RSP-18399] Buffer overflow in TWinControl.CreateParams() – Embarcadero Technologies but since that requires logon, it’s not search machine indexed so it’s very hard to find unless you know where to look.

So I spent a quite some time to find out what was wrong:

Since Delphi 1, the [WayBackControls.TCreateParams Record has a 64-byte WinClassName field that’s blindingly copied by the TWinControl.CreateParams without range checking.

The structure is used by the [WayBackTWinControl.CreateWnd Method to call the Windows API [WayBackRegisterClass function that takes a [WayBackWNDCLASS structure with a lpszClassName field that supports up to 256 characters and it fails when it’s longer.

That overwrite cause spurious other errors depending on the memory that gets overwritten. It took almost a day to figure out the cause of the error was this field, then an hour or to track that down to the long class names created by generic code.

To my surprise, I found back [WayBack] This issue caused coworkers and me quite a few hours wasted:Long story short – refactor some forms/frames to class names longer than 64 chars and boom… – Stefan Glienke – Google+.

As of Delphi 8 (yes, that version that a lot of people want to forget, but did bring a few good things), the structure was defined as below, and the code intialising also got improved:

Params.WinClassName := ClassName;
Params.WinClassName := Format('%s.%d', [Params.WinClassName, AppDomain.CurrentDomain.GetHashCode]);

So there it’s a string that – if it is too long – will get rejected by the Windows API anyway just like the native Delphi VCL implementation should have done 20+ years ago.

The sad part for FMX users: that structure and code got blindingly copied to the FMX.Controls.Win unit.

Read the rest of this entry »

Posted in Delphi, Development, Software Development | Leave a Comment »

%d bloggers like this: