Game directory, alternative to Program Files (in Windows)

Started by
8 comments, last by Aardvajk 11 years, 2 months ago

Hi! Just a simple cuestion, ¿What directory do your chose for install your games since Program Files is limited to read only?

Advertisement
Program Files isn't read only. Only members of the administrator group are allowed to write to it. This is also one of the reason UAC prompts for elevated privileges when installing a program: To write to the Program Files directory. That said, the "Program Files" directory should be static. Any program related data or user related data for that program should be stored in the user's %AppData% directory.

That said, it really depends on the game and how it's published. A zipped game that I'm previewing will be extracted and run from my desktop. A "heavier" game with an installer will be installed to the C drive (to a directory junctioned to the non-SSD drive).

The proper way is Program Files (the localized name of it must be retrieved). You can only store static data there, only the setup is supposed to use the admin user. The dynamic data should be written to the users appdata or own files folder. This way your game can run cleanly under a normal user.

Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

So, I can install all the static files in program files (like any other programs) and the dinamic files in the user's appData? That's mean that every user of the computer will have a diferent appData for my game, right?

How can I writte this directory in C++ for, per example, save the content of a ofstream object?

You'll need to euse some services provided by the operating systm. If you're targeting cross platform, then you'll also need to research how other operatoring systems handle the task. In Windows, you will need to use SHGetKnownFolderPath and CoTaskMemFree (as according to the documentation). Here's a simple demonstration:
#include <string>
#include <iostream>

// Win32
#include <windows.h>
#include <Shlobj.h>

// Link shell32.lib and ole32.lib libraries
#pragma comment ( lib, "shell32.lib" )
#pragma comment ( lib, "ole32.lib" )

int main() {
	PWSTR str = 0; // PWSTR is a typedef for wchar_t*
	if ( SHGetKnownFolderPath(FOLDERID_RoamingAppData, 0, 0, &str ) == S_OK ) {
		std::wstring wstr = str; // Note the w-string
		CoTaskMemFree(str);
		std::wcout << wstr << std::endl;
	}
}
Produces the following output:
C:\users\username\AppData\Roaming

There's some major gotchas here though if you launch the game from the installer. Consider the following.

User has a non-admin account but the password to an admin account. User runs the installer as themselves, gets the UAC prompt, enters the admin password. Game installs as the admin. Any attempt to access the APPDATA directory now returns the admin's appdata directory.

From what I can see, MS suggest writing all data on first launch, Fair enough,

Installer finishes and asks user if they want to launch the game. User says yes so game launches, still running in the admin account and writes its data to the admin user directory. User plays game, exits.

User runs game again - APPDATA is now the user's APPDATA directory. Hmm.

The only solution I can see is to no longer offer a launch option from the installer. We have a couple of applications at work that we want to launch from the installer since they should run on startup etc. I've spent a long time playing with different things in the Inno setup and cannot solve this. Currently seems the only solution would be to require a restart or a manual run of the application after the installer has finished.

I'd be interested in better solutions if anyone has one. It is not for no reason I suspect that Google Chrome installs its entire self into the appdata directory system and doesn't require admin permission to install. If there is no cleaner system than above, I suspect we'll see an increase in this behaviour which will largely circumvent and make useless the protection on Program Files at the current time.

Thoughts, anyone?

Installer finishes and asks user if they want to launch the game. User says yes so game launches, still running in the admin account and writes its data to the admin user directory. User plays game, exits.

runas /user:username game.exe?

When I stumbled upon this I separated the setup and a worker executable. The setup started would run as normal user, and only when the actual install process starts, the worker exe is running with elevated rights. Once it's done the worked ends and returns to the starter. The starter is still running under the starting user and can properly start the installed game.

Not really simple and also does not feel elegant, but gets the work done.

Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

Installer finishes and asks user if they want to launch the game. User says yes so game launches, still running in the admin account and writes its data to the admin user directory. User plays game, exits.
runas /user:username game.exe?

Thanks will look into that. Not sure how to get hold of the username though since the installer would be run as the adminstrator.

When I stumbled upon this I separated the setup and a worker executable. The setup started would run as normal user, and only when the actual install process starts, the worker exe is running with elevated rights. Once it's done the worked ends and returns to the starter. The starter is still running under the starting user and can properly start the installed game.

Not really simple and also does not feel elegant, but gets the work done.

Yeah, I looked into several Inno scripts that seemed to do similar but couldn't seem to get it to work properly. Need to look at again in more detail.

This topic is closed to new replies.

Advertisement