Jump to content
  • Advertisement
Sign in to follow this  
buumchakalaka

Game directory, alternative to Program Files (in Windows)

This topic is 2156 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement

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.

Share this post


Link to post
Share on other sites

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? 

Share this post


Link to post
Share on other sites
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 Edited by fastcall22

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!