PureBasic Forums - English

Rinzwind wrote: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.

I agree 100%.

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

Try to think this thing through

Who's going to do that?

Who has access to the code and can make changes and extensions in high quality.


Is the effort in relation to the effect ?

What are the most important open construction sites that should have priority ?

On the page of FreePascal I see eight developers presented who work on it

It is not difficult to see that here the tail is wagging the dog !

If crossplatform is the reason why windows specific library can't be added, then the native like commands such as "GetTickCount_()" should be removed too.

Saki wrote: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
Asking more often is rather counterproductive, as experience shows. LOL

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.

Full agreement!!!


Although I use Pb just for Windows and thus actually speak against myself, I consider a separate library for the registry as completely exaggerated:

• All registry accesses are guaranteed by Apis and are no science. This could perhaps be simplified a bit by a Pb support, but it doesn't change much.
• I cannot accept the argument that Pb also supports other operating system specific commands. These are additional commands to existing libraries, but not whole libraries that are only valid for one operating system.
• It is a bad habit anyway, that application settings are stored in the registry. They should be stored in an .ini, .prefs, .xml for whatever. These can then be used in other operating systems.
• 4) If anyone really wants to make changes in the system settings of the operating system, he should be familiar with the native Windows commands or better keep his hands off them.

leonhardt wrote:If crossplatform is the reason why windows specific library can't be added, then the native like commands such as "GetTickCount_()" should be removed too.

That makes no sense. Why removing API calls?
At the moment it is not that hard to read from and write to the registry using the normal Windows API. I don't think a native implementation into Purebasic would make it any easier. And I guess since Windows 10 there will be no more big differences here.

Finally if I understand some of you, these functions must disappear because they aren't cross-platform?
So why were they added?

https://www.purebasic.com/documentation ... cific.html

The more "basic" the code is, the easier it will be for many coders to understand. Native functions are essential.

Removing non-cross-platform functions makes no sense..


DesktopFrequency
AudioCDLength
EjectAudioCD
RawKey
ClearConsole
ConsoleCursor
ConsoleLocate
ConsoleTitle
EnableGraphicalConsole
DragFiles
DragPrivate
DragText
GadgetItemID
MDIGadget
InitScintilla
KeyboardMode
GetFunctionEntry
CountLibraryFunctions
ExamineLibraryFunctions
LibraryFunctionAddress
LibraryFunctionName
NextLibraryFunction
MovieAudio
MovieInfo
MovieLength
MovieSeek
MouseWheel
UseJCALG1Packer
CocoaMessage
SelectedFontColor
ChangeGamma
ScreenID
GetSoundFrequency
SetSoundFrequency
SoundPan
ThreadPriority
ToolBarStandardButton
SetWindowCallback
SmartWindowRefresh
PdfVectorOutput
SvgVectorOutput

Just to get back to what I was asking for, I know I can access the registry via api and I also know how. I know it's not a big deal to create an include. I just think it's better to include it in PureBasic natively. It's just 4 or 6 functions in the end (read/write/exist/delete...).

After using OS X and Linux, I find the Windows registry pointless and annoying for general applications. There's nothing you can put in the registry that you can not put/store in your own created file within your own application folder. Hiding registration keys or activation code in the registry is a joke. Also, I find it very annoying when you uninstall an app and its uninstaller doesn't clear out what it created in the registry. So I say, leave the registry alone and if you do create something in it, make sure your uninstaller cleans what your app or installer created.

@J. Baker
You mean like how OS X also leaves configuration files and caches laying around

As long as people program software, also OS, there will be errors.
Even crazy things.
Maybe one day artificial intelligence will free us from them.
Screwing with the Windows registry is not a good idea.
Now that we will stick to the concept of Win 10, the registry will never disappear again.
It is just a part of Win 10.
I don't think it's a good part, it's just too cluttered and opaque.
They say: "Many cooks spoil the broth".
It's also a fact that big companies start doing things that you think are controlled by the competition.

Are things or even states controlled by just one person,
everything stands and falls with this person and their views or even quirks;
For better or worse.

What a discussion

The registry is simply a relevant part of the windows operating system infrastructure. Purebasic is a language which does currently not offer native support. It is simply a negative point on the checklist of somebody who compares programming languages. That this can be easily solved is something they would realize much later. The initial comparision matrix of purebasic and many other languages simply has a missing feature "native windows registry support". The lack of native windows registry support, may simply lead to less sales and use because of that.

For such a simple and tiny library addition.

Guys, PB is multiplatform language, it means that it doesn't support all API or specific functions for all OS.
Registry is specific thing for Windows = nobody is limited to wrote own routines for it.
Not only for me are more important things to add to PB. At least support of AVR MCUs.

BTW: What is profit to use registry instead of separate configuration file?

Lukas

I have no opinion on this topic, I just want to throw in that there is an equivalent on most linux systems: dconf/gsettings. Besides this, I could imagine a more generalized library in PureBasic: System Configuration library. Common tasks could be included like

CreateDesktopShortcut (registry in windows, freedesktop .desktop file on linux, dunno what on mac)
AssociateFileType (registry, mime database)
SetAudioVolume
Enable/RunService()
Shutdown()
Restart()
...

They aren't all using the registry, but they are common tasks changing system properties.

Josh wrote:It is a bad habit anyway, that application settings are stored in the registry. They should be stored in an .ini, .prefs, .xml for whatever.

J. Baker wrote:There's nothing you can put in the registry that you can not put/store in your own created file within your own application folder.

l1marik wrote:What is profit to use registry instead of separate configuration file?

I wish people would stop saying that this is only about saving/loading our app data. It's not. As I said (twice now), access to the Registry is for reading and applying system settings that can't be done any other way.

I also like DarkDragon's idea of an enhanced System lib that can handle more generic PC settings.

BarryG wrote: As I said (twice now), access to the Registry is for reading and applying system settings that can't be done any other way.

Interesting, which exactly do you want to change, name them !