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,386 other followers

Archive for the ‘Delphi’ Category

Delphi: When porting really old code from versions that did not have .dproj files, watch your .dfg and .dof files

Posted by jpluimers on 2021/06/10

I have been bitten by this a few times too much, so time to write it down:

When porting old Delphi code from the Delphi 7 and older era, the options were stored .dof (options) and .cfg (configuration) files.

More modern Delphi versions try to translate these files when generating the .dproj file, in a similar way as they try to upgrade older .dproj files to newer formats.

Many things can go wrong, including these ones I have bumped into multiple times:

  • DCC_DebugInformation having a 0 or false value, but not handling these values correctly (I remember problems around the Delphi XE5 era with this: When the Delphi XE5 commandline compiler fails with error F1026: File not found: ‘False.dpr’)
  • DCC_OutputDependencies not being adhered to (no .d file is being emitted by the compiler), though for the .drc files, DCC_OutputDRCFile works fine)
  • DCC_DebugInformation having a 1 value (Limited Debug information) instead of being absent (Debug information)
  • DCC_SymbolReferenceInfo having a 1 value (Definitions Only) instead of being absent (Reference info)

–jeroen

Posted in Delphi, Development, Software Development | 1 Comment »

Delphi: .dproj TargetedPlatforms bit flags in main PropertyGroup, and Platform values in other elements/attributes

Posted by jpluimers on 2021/06/09

For cleanup of .dproj files, I want to know the bit flags that TargetPlatforms can have.

TL;DR: .dproj content management in Delphi is a mess

For future reference empiric values for the flags that build the TargetedPlatforms (not to be confused with PlatformTargets) element content in the main PropertyGroup of a .dproj file in a table.

This might help creating an XSD for a .dproj file (Source: Reminder to self: make a start for an XSD that validates Delphi dproj files).

Absent cells means I have no idea if the values are relevant or what they could be.

Input for those is more than welcome.

Bit# TargetedPlatforms bit flag value Platform and $(Platform)value Meaning (dropdown value of “Select Platform” dialog)
0 1 Win32 32-bit Windows
1 2 Win64 64-bit Windows
2 4
3 8
4 16
5 32
6 64
7 128
8 256
9 512
10 1024 iOSDevice64 iOS Device 64-bit
11 2048
12 4096

($Platform) values still to cover:

  • Android
  • Linux64
  • OSX32
  • iOSDevice32
  • iOSSimulator

There is only one place for TargetedPlatforms in the .dproj file: at the XPath /Project/PropertyGroup/TargetedPlatforms.

For getting the XPath, I used Notepad++ as described in my earlier blog post Getting the path of an XML node in your code editor.

It has the combined flags, so:

  • 3 means Win32 and Win64 are enabled
  • 1025 means Win32 and iOSDevice64 are enabled

The Platform value (and thus $(Platform) value) is the one used in for example these elements or attributes:

  • /Project/PropertyGroup/Platform as currently selected platform
  • /Project/PropertyGroup/@Condition as selectivity expression, for instance
    •  <PropertyGroup Condition="('$(Platform)'=='Win64' and '$(Cfg_1)'=='true') or '$(Cfg_1_Win64)'!=''">
    • <PropertyGroup Condition="('$(Platform)'=='Win64' and '$(Base)'=='true') or '$(Base_Win64)'!=''">
  • /Project/ProjectExtensions/BorlandProject/Platforms/Platform (all having for the value property with the Platform value) having a content of either True or False.
    • This allows a .dproj file to contain information for platforms that are not visible yet.

The actual values of Platform also play a role in these places:

  • /Project/PropertyGroup/Base_Win64 containing the base settings for the Win64 platform so they can be derived for the Debug or Release builds.
  • /Project/PropertyGroup/@Condition for instance <PropertyGroup Condition="'$(Base_Win64)'!=''">
  • /Project/ProjectExtensions/BorlandProject/Deployment/DeployFile/Platform/@Name for instance <Platform Name="iOSSimulator">

Even worse: there are unneeded  nodes present for bits in TargetPlatforms and /Project/ProjectExtensions/BorlandProject/Platforms/Platform being absent or having a content False for /Project/ProjectExtensions/BorlandProject/Platforms/Platform/@value other than the enabled bits in TargetPlatforms, for instance:

  • nodes matched by /Project/ProjectExtensions/BorlandProject/Deployment/DeployFile/Platform
  • nodes matched by /Project/ProjectExtensions/BorlandProject/Deployment/ProjectRoot/@Platform
  • nodes matched by /Project/ProjectExtensions/BorlandProject/Deployment/DeployClass/Platform/@Name (and the parent DeployClass subtrees)
  • nodes matched by /Project/ProjectExtensions/BorlandProject/Platforms/Platform@value

Some examples of superfluous nodes when TargetPlarforms has a value of 1 (corresponding to Platform having a value of Win32:

<ProjectRoot Platform="Android" Name="$(PROJECTNAME)"/>
<ProjectRoot Platform="Linux64" Name="$(PROJECTNAME)"/>
<ProjectRoot Platform="OSX32" Name="$(PROJECTNAME).app"/>
<ProjectRoot Platform="Win32" Name="$(PROJECTNAME)"/>
<ProjectRoot Platform="Win64" Name="$(PROJECTNAME)"/>
<ProjectRoot Platform="iOSDevice32" Name="$(PROJECTNAME).app"/>
<ProjectRoot Platform="iOSDevice64" Name="$(PROJECTNAME).app"/>
<ProjectRoot Platform="iOSSimulator" Name="$(PROJECTNAME).app"/>

Also, non relevant platforms are included in this node:

<Platforms>
    <Platform value="Win32">True</Platform>
    <Platform value="Win64">False</Platform>
</Platforms>

The Deployment section is even worse; see for instance [WayBack] delphi – How manage or clean deploy section in dproj files? – Stack Overflow.

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | 1 Comment »

Delphi: some notes on HModule while tracking down an access violation in TRegGroups.UnregisterModuleClasses

Posted by jpluimers on 2021/06/08

Too bad the whole mechanism involving TRegGroups.UnregisterModuleClasses is not documented anywhere

It is the underlying storage to support TClassFinder, which was introduced in Delphi 6, documented on-line in Delphi 2007, documented slightly in Delphi 2009, and since Delphi 2010 only one line of documentation was added (including the unchanged “instatiated”):

  • Delphi 2007: [WayBack] TClassFinder Class

    This is class Classes.TClassFinder.

  • Delphi 2009:[WayBack] TClassFinder Class

    The TClassFinder allows the list of registered persistent classes to be retrieved. Objects instatiated from persistent classes are those that can be stored (serialised) beyond the operation of the current application.

  • Delphi 2010:[WayBack] Classes.TClassFinder – RAD Studio VCL Reference

    TClassFinder allows registered persistent classes to be retrieved.

    The TClassFinder allows the list of registered persistent classes to be retrieved. Objects instatiated from persistent classes are those that can be stored (serialised) beyond the operation of the current application.

Back to TRegGroups.UnregisterModuleClasses: it takes a HMODULE parameter and ultimately gets called through the (since Delphi 2007) on-line documented [WayBack] Classes.UnRegisterModuleClasses Function

procedure UnRegisterModuleClasses(Module: HMODULE);

Call UnRegisterModuleClasses to unregister all object classes that were registered by the module with the handle specified by the Module parameter. When a class is unregistered, it can’t be loaded or saved by the component streaming system.

After unregistering a class, its name can be reused to register another object class.

To get more context about the access violation, I used both the stack trace and a debugging watch for GetModuleName(Module) (using the [WayBack] SysUtils.GetModuleName Function).

In order to see which classes were registered by what module, I set a breakpoint at in TRegGroup.AddClass (which can be called through various code paths):

procedure TRegGroup.AddClass(AClass: TPersistentClass);
begin
  FGroupClasses.Add(AClass);
end;

HModule

That gave me the class, but I also needed the HModule for a class, so I did a windows get module of currently executing code – Google Search, giving me these links, all C/C++ related:

Here you already see some confusion: there is HINSTANCE and HMODULE. That’s a historic thing, as described by Raymond Chen in [WayBack] What is the difference between HINSTANCE and HMODULE? | The Old New Thing:

They mean the same thing today, but at one time they were quite different.
It all comes from 16-bit Windows.
In those days, a “module” represented a file on disk that had been loaded into memory, and the module “handle” was a handle to a data structure that described the parts of the file, where they come from, and where they had been loaded into memory (if at all). On the other hand an “instance” represented a “set of variables”.
One analogy that might (or might not) make sense is that a “module” is like the code for a C++ class – it describes how to construct an object, it implements the methods, it describes how the objects of the class behave. On the other hand, an “instance” is like a C++ object that belongs to that class – it describes the state of a particular instance of that object.
In C# terms, a “module” is like a “type” and an instance is like an “object”. (Except that modules don’t have things like “static members”, but it was a weak analogy anyway.)

GetModuleName

Searching for delphi “__ImageBase” – Google Search then got me [WayBack] c++ – Get DLL path at runtime – Stack Overflow with a nice Delphi related answer by [WayBack] Ian Boyd:

For Delphi users:

SysUtils.GetModuleName(hInstance);              //Works; hInstance is a special global variable
SysUtils.GetModuleName(0);                      //Fails; returns the name of the host exe process
SysUtils.GetModuleName(GetModuleFilename(nil)); //Fails; returns the name of the host exe process

In case your Delphi doesn’t have SysUtils.GetModuleName, it is declared as:

...

This reassured my use of [WayBack] SysUtils.GetModuleName code was OK:

function GetModuleName(Module: HMODULE): string; 
var
  ModName: array[0..MAX_PATH] of Char; 
begin
  SetString(Result, ModName, GetModuleFileName(Module, ModName, Length(ModName))); 
end;

HInstance in Delphi

The example from Ian Boyd also brought back memories from long ago about the [WayBack] HInstance Variable – Delphi in a Nutshell [Book]:

Read the rest of this entry »

Posted in Conference Topics, Conferences, Delphi, Development, Event, History, Software Development | Leave a Comment »

Who maintains GExperts · GitHub?

Posted by jpluimers on 2021/06/03

I wnder who maintains [WayBack] GExperts · GitHub:

GExperts has 4 repositories available. Follow their code on GitHub.

It has not been updated for about 5 years, but contains some important bits.

–jeroen

 

Posted in Delphi, Development, GExperts, Software Development | 1 Comment »

Delphi: Passing build variables to batch files; I think the easiest is to use environment variables

Posted by jpluimers on 2021/06/02

A long time ago, I wrote about Delphi prebuild/prelink/postbuild events.

In practice, especially that you cannot inherit build events, then add new ones (), it is convenient to put all you need in a script, for instance a batch file.

Passing parameters to that script, then in my experience, is easiest to do as environment variables.

That way you can do this in a script:

> %temp%\build.txt echo ~dp0=%~dp0
>> %temp%\build.txt echo $(BDS)=%BDS%
>> %temp%\build.txt echo $(INPUTDIR)=%INPUTDIR%
>> %temp%\build.txt echo $(PROJECTDIR)=%PROJECTDIR%
>> %temp%\build.txt echo $(OUTPUTDIR)=%OUTPUTDIR%
>> %temp%\build.txt echo $(Platform)=%Platform%

if "%OUTPUTDIR:~0,2%"==".." set OUTPUTDIR=%INPUTDIR%%OUTPUTDIR%
>> %temp%\build.txt echo $(OUTPUTDIR)=%OUTPUTDIR%

Passing the parameters and calling the script results in this build event contents:

set Platform=$(Platform)
set INPUTDIR=$(INPUTDIR)
set PROJECTDIR=$(PROJECTDIR)
set OUTPUTDIR=$(OUTPUTDIR)
call ..\post-build-event.bat

The IDE then shows this fragment in the project output:

Target PostBuildEvent:
    set Platform=Win32&&set INPUTDIR=D:\Versioned\TestRepostitory\Test Project With Spaces\&&set PROJECTDIR=D:\Versioned\TestRepostitory\Test Project With Spaces&&set OUTPUTDIR=..\EXE Output Directory With Spaces\&&call ..\post-build-event.bat

The above batch file also shows things:

  1. how to handle relative directories in the OUTPUTDIR build parameter: check if the first two characters are .. (trick via [WayBack] Check if Batch variable starts with “…” – Stack Overflow).
  2. spaces are handled fine without any need to double quote the set assignments
  3. build-event lines are concatenated using the && success operator
  4. Parameters INPUTDIR and OUTPUTDIR end with a backslash, but PROJECTDIR does not (Delphi prebuild/prelink/postbuild events explains more about the parameters).

Note:

  • environment variable BDS does not end in a backslash
  • expansion %~dp0 does end in a backslash

With this trick now you can copy BPL files for the right platform:

xcopy /y "%BDS%\Redist\%Platform%\rtl250.bpl" "%OUTPUTDIR%"

Note that the LibSuffix (with value 250 for Delphi 10.2 Tokyo) is not available as environment variable, nor build parameter. The environment variable ProductVersion however (with value 19.0 for Delphi 10.2 Tokyo) is. So technically, you could make a mapping.

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

 
%d bloggers like this: