[Lazarus] Cross-platform using TRegistry - how to?

[Tony Whyman]

On 04/05/2020 11:05, Bo Berglund via lazarus wrote:
> On Mon, 4 May 2020 10:25:42 +0100, Tony Whyman via lazarus
> <lazarus at lists.lazarus-ide.org> wrote:
>
>> As to the filename issue: the xml file location is determined from the
>> Vendor Name and application name and relative to $HOME/.config - is that
>> really a problem?
> First off:
> I would NOT use the Registry ever for my new applications...
>
> Instead I would use conf files in ini file format so I can read/write
> them using the TIniFile or TMemIniFile classes.
If you are thinking of a new Linux app then I would agree. You only use 
TRegistry if its cross-platform and you need to use the registry under 
Windows.
>
> But my task now is to port a Windows service program which is
> controlling the scheduling of external equipment operations.
>
> It is a Windows service and thus non-gui but it implements a socket
> communications channel whereby existing Windows (Delphi) applications
> can control it by writing config data and look for results etc.
>
> We can no longer use the service application on Windows going forward
> because of Microsoft changes to drivers we rely on etc.
> So the idea is to convert the service application to FPC/Lazarus and
> then port it over to Linux.
>
> So, being a service the server uses the Registry for all of its config
> and task data on Windows and it would be simpler to port if I can
> continue using that part of the system.
> At first look TRegistry seems to handle this.
>
> But there is a problem:
>
> On Windows HKLM is a *global* hive and by what I hear here the
> TRegistry implementation for Linux uses xml files instead and that is
> no problem, provided that there is one only such file in use.
> But if they are application specific then it will not work.
> We use different applications to manage the server via the Registry
> and this would not work then.

The model is like Windows in that you have both system wide and per user 
hives. If you want a group of applications under the same user to access 
the same registry XML file then you need to make sure that they are 
using the same AppConfigDir. You can ensure this by adding Vendor Name 
and Application Name callbacks so that your applications all use the 
same AppConfigDir.

The issue that you may find is when one process makes a change to the 
XML file that needs to be picked up by the others. Then you may need 
some IPC signalling to make that happen. There may even be a need for a 
lockfile to avoid race conditions - but then you would have the same 
problem with .conf files.

>
> For example we have a local server configuration utility apart from
> the TCP/IP socket connection and if I understand it right this
> application would operate on a *different* xml file altogether so
> whatever changes it makes to the "registry" will not be available to
> the service application...
>
> If this is so I need to reconsider the use of TRegistry and dig down
> into changing to conf files (which can be global)...
> Much more code to convert in that case.
>