In VB you could write and read program configuration parameters to the windows registry using GetPrivateProfileString and WritePrivateProfileString. How does this work while writing a multi platform application given that OSX does not have a registry. The second that you attempt to invoke a windows function such as the above mentioned the IDE will surely have a conniption.
You need to wrap your platform specific code in pragma commands e.g.
// Do some Windows stuff here
This tells the compiler to include/exclude code based on your target preferences. Using remote debugging if the target is another platform that binary will be built and transferred using the pragma commands you specify.
Wayne, thanks for the quick response. Does this mean that if you are writing a multi platform app, you have to write a config file method for OSX and a registry method for windows? How does one obfuscate configuration settings in OSX?
Yes, but that is a consequence of being able to build an xplat solution. As to your second question I have no idea - I write for Windows. I would say that writing to the Windows registry does not obfucsate your settings.
Alternatively, you could save the settings to a flat file either in the ini, xml, json or your own style. This will give you the flexibility on how you want to obfuscate the settings and should work on any platform.
For sake of precision, neither these functions wrote or read to and from the Registry. These functions were used to manage INI files.
There are classes around in the forum to manage INI files. If memory serves me well, @Dave S and @Mark Strickland among others wrote INI file management classes. These classes could be used on any OS as far as I understand them since they are using strictly Xojo code.
Thanks Louis, but I think that Microsoft disagrees with you:https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-getprivateprofilestring
No, Louis is right.
PrivateProfileString is for reading and writing to an INI file and has been there for a very long time.
Around or just after XP (can’t recall when), this clause shows what Microsoft did next…
In practice, I found that writing to the INI file caused Windows to create a copy in ‘the registry’ (pretty sure its ‘a registry’) , but roaming profiles and the wish of Microsoft to protect ‘the real registry’ seems to cause copies to appear in user level settings area…
I’ve seen systems where it was a maze trying to guess where Windows was actually holding one or more copies of the setting.
(why ? trying to delete settings without having access to a program’s original source code)
This mapping is likely if an application modifies system-component initialization files, such as Control.ini, System.ini, and Winfile.ini. In these cases, the function retrieves information from the registry, not from the initialization file; the change in the storage location has no effect on the function’s behavior.[/quote]
You could encodebase64 as a simplistic method
Both Jeff and Louis are telling me something and I am just not getting it. I wrote several apps from 1998 to 2002 in VB and they all stored settings in the registry. You could fire up regedit and see the keys and data. Are you telling me that didnt happen or am I just a bit thick today.
Yes it happened.
Windows mapped your INI file calls to store stuff in a registry.
The important thing here is, you aren’t only targetting windows now.
You may as well ditch the idea of the windows way and use something that works cross platform, or fight with #target pragmas
Agreed, its getting all too hard trying to satisfy both silicon universes.