Question to Windows users

[hgm]

What would be the best place in modern Windows systems to store the user settings file of a GUI? For WinBoard I so far always used the user's Application Data directory:

C:\Documents and Settings\<user>\Application Data\ on XP
C:\Users\<user>\AppData\ on Vista
C:\Documents and Settings\<user>\AppData\Roaming\ on Win7 (it seems)

But I now get complaints that these folders cannot be written without administrator permission. (And it is hidden.)

Is this really unintended use of the AppData folder? Where else would a user expect a settings file for an application he installed? Should the winboard.ini file be better located in his "My Documents" folder?

[Edoardo Manino]

I'm a win7 user,
the MyDocuments folder won't give you any permission problem.
I had similar problems in installing on the C: drive a program that writes some file as output. those file were deleted automatically by the OS until I moved the program in the MyDocuments folder.
Edoardo Manino

[Giorgio Medeot]

I think you should use something like

Code: Select all

%AppData%\winboard\winboard.ini

and leave to the OS to decide where it would go.
About your second question: yes, that folder should always be writable by the current user (but not by other users). It is hidden by default, but it doesn't matter, as users are not really meant to directly edit something there (only their applications).

Cheers,

• Giorgio

[hgm]

I think you should use something like

Code: Select all

%AppData%\winboard\winboard.ini

and leave to the OS to decide where it would go.

Indeed, this is somewhat like I am doing now. Except that I use

Code: Select all

%APPDATA%\winboard.ini

directly, as creating an extra folder just to hold a single file did not seem to serve any purpose. Or could this be a problem on Win 7?

[lucasart]

What would be the best place in modern Windows systems to store the user settings file of a GUI? For WinBoard I so far always used the user's Application Data directory:

C:\Documents and Settings\<user>\Application Data\ on XP
C:\Users\<user>\AppData\ on Vista
C:\Documents and Settings\<user>\AppData\Roaming\ on Win7 (it seems)

But I now get complaints that these folders cannot be written without administrator permission. (And it is hidden.)

Is this really unintended use of the AppData folder? Where else would a user expect a settings file for an application he installed? Should the winboard.ini file be better located in his "My Documents" folder?

On Windows, the proper place to store application settings is in the system registry. Using ini files is what people did back in the Windows 3.1 days.
Then you need to package Windoard with an installer, like NSIS for example. And the uninstaller does the cleanup.

Also, the folders you mention should never be hardcoded in your program. There are Windows API that give you the location of folders like Windows (often c:\windpows but can be different), Temp, System, My Documents, etc. All these folders have theuir default value change from a version of Windows to the next, and even on a given version nothing is written in stone (you can decide to install windows on c:\windaube if you prefer)

This is ugly, but uglyness is what Windows is all about, right ?

[Modern Times]

What would be the best place in modern Windows systems to store the user settings file of a GUI?

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

[hgm]

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.

[hgm]

On Windows, the proper place to store application settings is in the system registry. Using ini files is what people did back in the Windows 3.1 days.

The WinBoard (and XBoard) ini file mechansim is extremely powerful, and I don't think you could accomplish anything close to it using the registry. (You would need something more like a 'wizzardry'. )

Then you need to package Windoard with an installer, like NSIS for example. And the uninstaller does the cleanup.

Well, this is exactly what we do.

Also, the folders you mention should never be hardcoded in your program. There are Windows API that give you the location of folders like Windows (often c:\windpows but can be different), Temp, System, My Documents, etc. All these folders have theuir default value change from a version of Windows to the next, and even on a given version nothing is written in stone (you can decide to install windows on c:\windaube if you prefer)

Also this is taken care of. The names are not even in the program code, but imported from a master settings file that resides in the WinBoard installation folder. And in the settings file they are specified in symbolic form, like %APPDATA% or %HOMEPATH%, so that the OS can expand them according to the conventions of the Windows version in use. But the question was not so much wich would be the exact pathname to use, but more what the convention is for storing this type of application files.

[stegemma]

On Windows, the proper place to store application settings is in the system registry. Using ini files is what people did back in the Windows 3.1 days.

The WinBoard (and XBoard) ini file mechansim is extremely powerful, and I don't think you could accomplish anything close to it using the registry. (You would need something more like a 'wizzardry'. )...

That's not true. You can simply load ini file to a string and save it to a single entry in the registry, then you can read back that entry in one string and parse it, as you would do with ini file. The only problem is that users can't easly modify the registry (they should use regedit) but this is the preferred method on Windows, to store user parameters.

[mar]

That's not true. You can simply load ini file to a string and save it to a single entry in the registry, then you can read back that entry in one string and parse it, as you would do with ini file. The only problem is that users can't easly modify the registry (they should use regedit) but this is the preferred method on Windows, to store user parameters.

I believe Windows registry is the second most unfortunate Microsoft invention (with #1 being backslashes in pathnames).