Question to Windows users

[hgm]

But the point is that you can have many ini files, recursively invoking each other, and redefining where the settings will be stored on exit. And the possibility to edit the ini file adds important flexibility.

I admit that I don't know how to handle the registry at all; I am just a C and assembly programmer, not a Windows expert.

One example of the power of WinBoard/XBoard's settings system is that tourney files are normal settings files, so that you can easily add all kind of non-standard settings to a tournament. And that you can start XBoard instances running tournament games by simply clicking the tournament file.

[Michel]

I believe Windows registry is the second most unfortunate Microsoft invention

I don't understand why people say this. A global database to store configuration information in seems to be quite sensible to me.

I think they messed up the interface (HKEY_LOCAL_MACHINE ??? what is that???). But the basic idea is good and has been copied by gnome and kde (and probably by many other guis).

[mar]

I don't understand why people say this. A global database to store configuration information in seems to be quite sensible to me.

I think they messed up the interface (HKEY_LOCAL_MACHINE ??? what is that???). But the basic idea is good and has been copied by gnome and kde (and probably by many other guis).

Well a global ever growing (files), absolutely non-transparent, nonportable.
Saying that many apps don't clean up properly is the least evil here.
The larger it grows, the slower the boot time for some reason.
Windows registry holds much more important information than just user-app configuration, like apps to load at startup and much more.
Do you really believe it's good to have all such important information together in one/more frequently changing file(s)?
Also it has always been a heaven for all sorts of malware.
One word to characterize registry which comes to mind is mess (not to be confused with recycle bin .
Please note that I'm not a Windows hater.

[stegemma]

But the point is that you can have many ini files, recursively invoking each other, and redefining where the settings will be stored on exit. And the possibility to edit the ini file adds important flexibility.

I admit that I don't know how to handle the registry at all; I am just a C and assembly programmer, not a Windows expert.

One example of the power of WinBoard/XBoard's settings system is that tourney files are normal settings files, so that you can easily add all kind of non-standard settings to a tournament. And that you can start XBoard instances running tournament games by simply clicking the tournament file.

To manage the registry you can use Windows API. You could start from here:

http://msdn.microsoft.com/en-us/library ... s.85).aspx

Using Windows API is not simple but they works... sometime

But the fact is: if you are in a Windows environment you have to follow Windows guidelines and Microsoft says that one should use the registry, instead of ini files. Ini files are simpler and users can edit them but is is not the preferred method. Me too i use saving program data in the root of C: disk (bad, very bad thing!!!) after the Windows Vista/7 news that they lock program files directory. I know that it's the worst thing to do... but i do it. So you can keep using ini files, but just know that it is not the "legal" choose, under Windows.

[hgm]

Just for my understanding:

Is the registry a global thing, or does every user has his own registry? Or would it be necessary to somehow incorporate the name of the current user in the name of the keys he stores. On principle it would be possible to integrate the ini file and registry mechanisms for storing settings: I could extend WinBoards routines to open ini files for reading and writing to also offer the option to read and write registry keys. E.g. by assigning pseudo-filenames to keys, like Reg:KEYNAME for a key with the specified name, and have the routines test for the Reg: prefix, and load or store the offered data to that key in stead of a file.

But I think there is sufficient justification to violate the recommendations, by arguing that WinBoard settings files are really documents belonging to the application. For tourney files that is obviously true, and they are just a special kind of ini file. So it must be true for all ini files.

This, of course, would suggest that the users's My Documents\WinBoard would be the proper place to store them.

[plattyaj]

Just for my understanding:

Is the registry a global thing, or does every user has his own registry? Or would it be necessary to somehow incorporate the name of the current user in the name of the keys he stores. On principle it would be possible to integrate the ini file and registry mechanisms for storing settings: I could extend WinBoards routines to open ini files for reading and writing to also offer the option to read and write registry keys. E.g. by assigning pseudo-filenames to keys, like Reg:KEYNAME for a key with the specified name, and have the routines test for the Reg: prefix, and load or store the offered data to that key in stead of a file.

One registry but with sections of it that are per-user. They have pseudo-keys in the registry that point to the "current" user so you just access them through that.

Specifically it is \HKEY_CURRENT_USER.

System-level parameters (usually installation information) can be kept in global sections.

[mar]

Just for my understanding:

Is the registry a global thing, or does every user has his own registry? Or would it be necessary to somehow incorporate the name of the current user in the name of the keys he stores. On principle it would be possible to integrate the ini file and registry mechanisms for storing settings: I could extend WinBoards routines to open ini files for reading and writing to also offer the option to read and write registry keys. E.g. by assigning pseudo-filenames to keys, like Reg:KEYNAME for a key with the specified name, and have the routines test for the Reg: prefix, and load or store the offered data to that key in stead of a file.

But I think there is sufficient justification to violate the recommendations, by arguing that WinBoard settings files are really documents belonging to the application. For tourney files that is obviously true, and they are just a special kind of ini file. So it must be true for all ini files.

This, of course, would suggest that the users's My Documents\WinBoard would be the proper place to store them.

The user has its own registry (but one can still access some common global values via HKEY_LOCAL_MACHINE).
It can be accessed via HKEY_CURRENT_USER, so no need to incorporate user name into keys.

I would have no problem with "My Documents" (some programs ask whether to install for current user only or all users - so perhaps My Documents/User/Winboard?).
In fact I always installed Winboard separately (not in Program Files) so I never had any problem with it.

[stegemma]

...

But I think there is sufficient justification to violate the recommendations,...

Often is Microsoft itself that violates its own recommendation or simply change his mind.. so don't worry about that

You can also be a bad boy... and store all you want in C:\winboard and nobody will worry at all about this little violation.

[F. Bluemers]

In the same folder as the program installation ? And please not in the registry.

This is of course exactly what older WinBoard versions (before 4.5.0) did. But when Windows started evolving into the direction of a multi-user OS this was no longer satisfactory. All users would share the same settings file, and spoil each others settings. In addition, security policies have been tightened, and normal users usually have no longer write access to the folder where WinBoard is installed. So they could no longer save their settings at all...

In the modern philosophy of Windows, programs are expected to store their settings on a per-user basis. Without the need for each user to do a separate install in his My Documents folder.

Some users might want a "per instance" ini file,where each winboard would run from its own folder with its own ini file.
Maybe with an option?

[stegemma]

...
Some users might want a "per instance" ini file,where each winboard would run from its own folder with its own ini file.
Maybe with an option?

In an old program i've done something like this: if there are the ini file in program folder, i load it and use it; if not then i searched the registry. Another solution is simply to add a program parameters in command line, like this:

winboard -useregistry
winboard -useini=somepath/inifile.ini