Native Registry Support

[Jac de Lad]

As the title suggests I would like to have native registry support for windows. There's a module from ts-soft, but something official or native support would be a better solution.

[Saki]

Unfortunately
This is not Multi OS, so it will probably not exist

[Rinzwind]

Thats the weak excuse we got, however each platform has its own specific ways/standards. Some should be considered “essential” for the platform, and as such included.

Because of this refusal, we get to reinvent the wheel or sometimes use untested or unstable code because theres also a lack of time tested open source third party libraries. macOS has plists (also not supported in any way, not even when compiling), Windows registry, Linux config files.

This stands alone from the fact that Im not a fan at all of the registry idea and execution. It can be quite a mess. Still, it should be supported. FreePascal has it too, which is a compiler that has more architecture targets than PB.

PBs official ecosystem has to grow, supporting each platforms uniquenesses.

[Marc56us]

Unfortunately
This is not Multi OS, so it will probably not exist

There are a number of functions that only exist for certain platforms.
See: List of Platform-dependent Functions
There may be another reason why registry functions are not implemented.

[Bitblazer]

A command set which focuses on functionality could be offered and the actual implementation is platform dependant. For example a "configuration" commandset which is able to store and retrieve integer, float and text fields plus has the additional ability to store/restore the set of all current configuration settings into a portable file like an XML file. It should be based on something like an application unique identifier so you could use it to support thousands of applications/tools on the system.

If you wanted to be nice, the storage file could use some version of XML. So thirdparty tools could implement additional features like the ability to pick up all pathes used by one application in another. Some path settings are pretty common and could be shared. Personally i would implement it using an initialisation call where the applications name is passed. For windows, it would actually use a registry/localmachine/currentuser/appdata path.

Purebasic could (and should!) make application settings as portable as the applications already are.

[BarryG]

There may be another reason why registry functions are not implemented.

The Registry is a major functional part of the Windows platform (Windows can't even be used without it), so a Registry library should definitely be included. It's not used just to store/get app settings, but for PC configuration, tweaks, and data info about the PC's runtime state. I've never understood why it's been overlooked for so long despite many multiple repeated requests (like this new thread).

[Mindphazer]

The Registry is a major functional part of the Windows platform (Windows can't even be used without it), so a Registry library should definitely be included. It's not used just to store/get app settings, but for PC configuration, tweaks, and data info about the PC's runtime state. I've never understood why it's been overlooked for so long despite many multiple repeated requests (like this new thread).

As you say, the registery ONLY EXISTS on Windows.
PureBasic is NOT exclusively a Windows application.

And, in my modest opinion, registery is probably the ugliest thing ever done

[BarryG]

PureBasic is NOT exclusively a Windows application.

And as Marc56us showed, there's plenty of Windows-only features in PureBasic already. This would just be one more that enables so much more functionality for PureBasic without everyone needing to share and rely on a Registry lib or module from someone.

[Saki]

$ You can request features against payment.

So you can just make an offer

[Rinzwind]

Payment? Thats never been discussed openly and officially too. Its all about what one person thinks is right. As said PB is unfortunately not an community effort. All we can hope for is that feature requests get some attention. Oo Fred is more than welcome to add his “price” To this topic. Seriously.

[NicTheQuick]

Then also please add dconf support natively. It's only fair.

[Saki]

Payment? Thats never been discussed openly and officially too.

But it was, this is nothing new

[Jac de Lad]

However, some programming languages implemented a dedicated solution for non windows platforms, storing that information in a file with similar structure. This won't port the information you can get via registry on windows to other is, but is suitable for storing information intended by the developer.

Also however, being limited to windows doesn't seem like a valid excuse to me. Thinking of SendMessage right now...

[BarryG]

Then also please add dconf support natively. It's only fair.

But dconf isn't needed for Linux to run, is it? Quote from your link: "Its main purpose is to provide a backend to GSettings on platforms that don't already have configuration storage systems." So it looks like an optional storage system, rather than something vital. That's the difference. Windows can't even boot without the Registry.

As I said, Registry access isn't just for saving/loading app data as a storage system. We can already easily do that with INI files and/or the Preferences() lib. The Registry holds PC state settings that are useful to read that isn't available any other way (such as when no API exists for it).

Payment? Thats never been discussed openly and officially

But it has been accepted and done before (see two sponsors here -> viewtopic.php?f=14&t=70785).

Thinking of SendMessage right now

Isn't CocoaMessage() the Mac equivalent of that?

[Saki]

The discussion about this is rather pointless.

There are in itself only three criteria

1. suggest a feature and wait to see what, or whether something will come up over time.

2. make a financial offer for the implementation

3. change the programming language if the desired feature is indispensable

Common program parameters can be created in a structure and stored in the user folder.
The read and write access can be done binary and is very easy to implement, this is then Multi OS.

OS specific access to the Windows registry is a completely different matter, just special.