NTFS features for storing your program settings

In Windows, there are several ways to store program settings. Registry, ini files, other file types (at the discretion of the developer). Sometimes it is more convenient one thing, sometimes another ... Each approach has its own advantages and disadvantages. I propose to understand what is better and offer an alternative that combines the advantages of several approaches.

The registry is convenient because the settings are all in one place and do not hang out next to the program. But it is not very convenient if you need to use multiple copies of the same programs (utilities), but with different settings at the same time. Then, when writing a program, you have to take this into account and come up with something to implement saving for each copy of the program separately. For example, select the registry key, which will also include the name of the executable file.
* .ini files, as well as other configuration files, are convenient because they store the settings of the program with which they are directly located. Thus, you can keep several copies of programs with different settings (and, moreover, when the programs are in different directories). But you have to drag these files next to the program. And if the program is not large, in which one exe file is enough, and no unnecessary files and resources are no longer required, then these configuration files as a load hang over the soul.
I want to tell you about an alternative place where you can save the program settings so that there are no settings files next to it, and at the same time there are different settings for each exe file, even if they are in the same directory. This method works only on NTFS, because uses the capabilities of the file system itself.
Files in NTFS have so-called “file streams”.

How is this implemented? Any information about the file, starting with its name, permissions and ending with the actual data stored in the file, from the point of view of NTFS is an attribute stored in its own stream (stream).

Usually the file has one stream - the main one. In general, any file can have as many streams as you like. A multithreaded file is a kind of collection of single-threaded files, which from the user's point of view looks like an indivisible unit. In fact, this is a set of file streams, each of which can be independently created, edited and deleted. Each additional stream has a symbolic name through which it is possible to access data in this stream. For example, "Program.exe: stream". The stream itself is created when you first open the record and then you can work with it as with a regular file.
Here is an example of C ++ code for working with a stream.

 void read_settings(){ try{ ifstream file("Program:settings"); char* ProgramTitle = new char[256]; file >> ProgramTitle; } catch(...){ //     } } 

Similarly, to write to the stream.
Thus, we get the ability to store settings directly in the executable file itself. Moreover, these settings will not go anywhere from the file, as well as for each exe file, you can save your individual settings. Well, if you want to divide the settings into categories or something else, you can create several streams for each type of settings.

This method of storing settings is convenient if the application is not large and consists of a single executable file. As well as storing settings in the stream in some sense increases security, because You can read the information only if you know the name of the stream. But to find out what streams are in the file and whether they are there at all is not always easy. Most likely, there are API functions that let you know which threads are in the file. But the person who is completely unaware of their existence of these possibilities will not guess where the settings are stored.

There are small disadvantages of this method. It should be borne in mind that when transferring such a file, only the main unnamed stream is copied to a partition with a different file system. It makes sense to use such files only with the NTFS file system.
Also, if we want to transfer the settings somewhere to a separate place, then we will have to write the export procedure.
But otherwise I think this method is quite flexible and convenient. It turns out portable applications with the ability to configure.