Recent

Author Topic: TRegistry - cleanup and fixes  (Read 16107 times)

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: TRegistry - cleanup and fixes
« Reply #30 on: February 13, 2019, 10:27:53 am »
Also IMHO we should drop the non-windows implementation of Registry and make it a Windows only package.
I cannot believe that any person of sound mind would use TRegistry or TRegIniFile on such a platform.
Better alternatives exists: TIniFile (a sort of native solution for *nix) or TXmlConfig.

I'm quite sure the fpc devels will not agree on that last point though.
Correct. Because that would be a break of backwards compatibility and considering that we receive bug reports about this feature people are using it.

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: TRegistry - cleanup and fixes
« Reply #31 on: February 13, 2019, 12:27:41 pm »
Correct. Because that would be a break of backwards compatibility and considering that we receive bug reports about this feature people are using it.

Well, we could poll to see if anybody uses that at all?
We could deprecate it and remove it in 4.0?

Why would a *nix user expect that a TRegistry implementation exists at all?
It's like Windows users expecting to be able to use package cocoaint, dbus or libcups.

Bart

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: TRegistry - cleanup and fixes
« Reply #32 on: February 13, 2019, 12:46:39 pm »
Why would a *nix user expect that a TRegistry implementation exists at all?

A *nix user wouldn't even think about it but a developer porting a Windows application making heavy use of it would probably be mighty thankful to have it. Just as a *nix user porting an app to Windows would appreciate having DBus there instead of having to learn how to do things with COM or whatever :)
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

CCRDude

  • Hero Member
  • *****
  • Posts: 596
Re: TRegistry - cleanup and fixes
« Reply #33 on: February 13, 2019, 12:50:08 pm »
I can confirm that: as someone porting software from Windows to Linux and MacOS, I'm glad about that feature, since it allows me to port existing code easily, without having to port the settings storage to a platform independent solution first.

On the other hand, as a mid- to long-term solution for software I port, I prefer the mentioned alternatives, since even on Windows, they would add the benefit of easier conversion to a portable app, for example.

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: TRegistry - cleanup and fixes
« Reply #34 on: February 13, 2019, 12:54:55 pm »
On the other hand, as a mid- to long-term solution for software I port, I prefer the mentioned alternatives, since even on Windows, they would add the benefit of easier conversion to a portable app, for example.

Yes, I think the same. In fact, IIRC, I have used the registry (in Windows) for config storage in just one app and that only because I was forced to do so (by the then boss).
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: TRegistry - cleanup and fixes
« Reply #35 on: February 13, 2019, 02:17:49 pm »
Well, the drawback is that if you fix TRegistry on Windows (so you probably are a Windows developer or at least have a Windows machine for development, and you have at least a rudimentary knowledge of TRegistry and the Windows API it uses), you may accidentally break the not-Windows part of it.
This will result in rejection of the patch unless the not-windows side is fixed.
And who is going to do that?

No devel uses TRegistry.
No Windows user uses the XML implementation of TRegistry.
No Linux user in his right mind uses TRegistry.
So, it's up to whoever fixed TRegistry on Windows to fix code he/she most likely knows nothing about, nor wishes to know anything about, nor wishes to use it before hell freezes over.

This is truly motivating for people supplying patches.

Note: I supplied patches for TRegistry and TRegIniFile, I don't even use TRegistry (let alone TRegIniFile) anywhere. I'm not going to try to fix things on the not-Windows side if that got broke (I just hope my patches did not).

Bart

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: TRegistry - cleanup and fixes
« Reply #36 on: February 14, 2019, 09:16:48 am »
Correct. Because that would be a break of backwards compatibility and considering that we receive bug reports about this feature people are using it.

Well, we could poll to see if anybody uses that at all?
We could deprecate it and remove it in 4.0?

We receive bug reports for it, so there is no need for a poll as there clearly are users using it. And as the others mentioned: it eases porting.

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: TRegistry - cleanup and fixes
« Reply #37 on: February 14, 2019, 10:53:01 am »
We receive bug reports for it, so there is no need for a poll as there clearly are users using it. And as the others mentioned: it eases porting.

Fair enough.

Bart

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: TRegistry - cleanup and fixes
« Reply #38 on: February 23, 2019, 05:27:52 pm »
Well, we're getting somewhere:
r41325+41352: Fixed bug 35060, proper unicode-handling of registry-keynames
r41415: fix writing unicode strings in the Windows registry

Remaining issues:
#0035022: TRegIni.WriteString writes to wrong Key (patch fixes also #0035023 and #0033980).
#0034876: TRegistry's rdMultiString treats Unicode strings as AnsiStrings (patch attached).
#0035132 TRegistry.DeleteKey inconsistent behaviour Windows vs other platforms (patch and test attached). (DeleteKey on non-Windows acts as DeleteTree)

If all this is fixed I can write a TRegistry.DeleteTree implementation.
(My first attempt to do this remove the entire HKCU\Software section when I ran the code in Delphi for comparison. In the end I had to delete my account and recreate it...)

Bart

 

TinyPortal © 2005-2018