Tested my game on Vista

Tested Holiday Bonus on my partner's new Vista Laptop (HP HP NX7400, Core 2 Duo, t7200-2.0GHz, 2GB Vista Business, Intel GMA 950 Grapics) today and can state the following:

0) When I ran setup (made with Innosetup) I got a UAC warning, but was able to run it fine.

1) My innosetup installer (made in Dec 2006) worked fine BUT it had a LONG delay when creating shortcuts, perhaps it's because Vista didn't like my "naughty" shortcut locations (Desktop and Program Files) or some crap.

2) Game ran fine, no crashes. It's wrapped with Armadillo and had the usual splash screen so glad that worked. Haven't tried unlocking it with a key yet though.

3) Horrible one second sound delay on everything. Using BMax and FreeAudio. Haven't tried OpenAL yet.

4) Music breakup. I'm playing oggs with FreeAudio (loaded fully into memory) and occasionally the cut out totally for a few seconds then come back in. Nice.

5) My panning zooming christmas tree was smooth which was a good sign. Game was running at 60FPS but I'm pretty sure I saw the odd jerk/slowdown when particle effects kicked in, but I know that Vista was downloading all sorts of stuff in the background from the Internet. Haven't been able to test the full frame rate yet as I disabled Vsync on/off toggle in the commercial release. Default mode as DX not OpenGL. I'll test both later.

6) The game was "stretched" to fill the widescreen which is a bit rubbish. It should be 800x600 but I guess the laptop didn't use the correct aspect ratio and bars. I guess this is a driver setting somewhere until I make my framework auto-detect if it's a widescreen laptop and pick the correct res.

Anyone have any info about that graphics chip? I know it's probably crap but I'm interested in HOW crap.

GMA950 isnt as crap as anything less than the 950 - the card implemented some new stuff in hardware.

http://www.intel.com/products/chipsets/gma950/index.htm

I am running Holiday Bonus on Vista almost since the first day you started selling it and I am not experiencing the problems you are describing. The only difference is that UAC is disabled on all of my machines.

Core2Duo, ATI X1950XTX

Barney

Is your game data saved to the correct place (i.e. local appdata) or is it getting dumped to virtualstore?

The latter would need addressing.

FreeAudio is buggered on Vista. Completely. I'd use either OpenAL, although DirectSound seems to work perfectly, too - even though a while ago a few people said they had crackling problems with it.

Cygnus: But I wonder what it's speed is compared to proper 3D cards. Hey is there any way to find out how much VRAM it has?

Barnabius: That's great! It's just that sound driver is not good on many Vista PCs. You are lucky that it's OK on yours :-)

GfK: No it's not saving to the correct place. When I wrote that game I hadn't even looked into it. I'll fix it for the re-release of Holiday Bonus GOLD on PC and Mac this year. Remember some people reported OpenAL issues too (on Indiegamer) but if it's better than FreeAudio...I personally experience a bit of crackling with DirectSound on XP, but nothing major - it just sounds "noisy".

Grey, check in the bios for a vram setting. you can usually modify it

the GMA950 is a very low end card. Probably a GF3/4 equivalent, so not slow, but certanily not anything fantastic :)

The GMA 950 is 'powerful' enough to run Vista's Aero interface and it is also good enough to run Linux' Beryl and Compiz 3D GUIs.

I've never used it with games, but since Vista gives it a performance index of 3, it should be good enough for Quake 3 and Unreal 2 engine based games.

The GMA950 is quite wide-spread, especially on machines that the typical casual games uses in the office and at home, so you would be well adviced to test your games with it. ;-)

Yeah it got a performance index of 3.1. The rest of the Laptop is up in the 4s. Can you get higher than 5?

Cyg: GF3/4 isn't bad!

Oh, it's not that new then? Yeah I'll test out max speed on it soon.

Could someone remind me ( or point me to ) the definitive answer on where to put files on Vista? Since I've got Vista now, I may as well spend an hour rewriting the file handling to ensure it works with Vista and UAC. All I can find on a search is that you can't do it without setting up the installer to do the file permissions, which I would prefer not to do as I have no idea what installer I may end up using.

I plan to sort this properly in about a month when I'm back from holiday. I too don't like the idea of using the installer because the portals can't be relied upon to do important stuff in their installers.

Here's some links I have stored ready to harvest for info:

http://msdn2.microsoft.com/en-us/library/ms995853.aspx
http://msdn2.microsoft.com/en-us/library/bb206295.aspx
http://forums.indiegamer.com/showthread.php?t=10111
http://www.blitzbasic.com/Community/posts.php?topic=70424
http://www.blitzbasic.com/codearcs/codearcs.php?code=1978

I'm pretty sure there was a big Vista thread (or two) here too a while ago (2 months?) but I don't have it bookmarked. If you find it please post a link

Oh and here's my Vista to do list:

screenshots in "My Documents" (or whatever the Vista equivalent is called) with CSIDL_PERSONAL. 

High Scores, profiles folder and ini settings (need to be created on first run) stored in CSIDL_COMMON_APPDATA (C:\Documents and Settings\All Users\Application Data\
)

When making wallpaper, need to save the file to a temp location first.  Maybe also in CSIDL_COMMON_APPDATA

change restore ini code.

Write inichanged.dat and goodexit.dat to CSIDL_COMMON_APPDATA

Look for other file operations and change.

Did you ever figure out how to set folder permissions for CSIDL_COMMON_APPDATA?

No. I *still* haven't implemented this. Indiepath did it via an installer but that's no good.

That's the only way I found to do it, too.

However, Oberon Media told me to use LOCAL_APPDATA instead so it became a non-issue for me.

But if you store global high scores in Local_APPData and someone logs onto widows with a different profile, you won't be able to read the global high scores right? Local AppData is a path within the logged on user's profile isn't it?

OK done some more Holiday Bonus testing and found out some pretty important stuff.

To conclude: When your game uses Virtual Store it works fine for one windows account but does not work as expected for multiple windows accounts.

First install:

1) I installed the game on the main administrator account called Helen and the installer brought up the UAC prompt to boost its priviliges. The installer auto launched the game at the end because I left that option ticked.
2) I created a profile in my game and changed some options which wrote to the ini file.
3) I exited the game.
4) I went back into the game and made another profile and also changed some more ini options.
5) I exited the game and went back in and the new profile was there and the ini options were correctly applied.
6) Now it gets interesting ... I made a second Windows user account called Jake, I didn't give it administrator priviliges (although I don't think this has any bearing on the test results).
7) I switched to the new account and obviously Holiday Bonus didn't have an icon on the desktop (because the account was created after the game was installed) so I made a shortcut to it.
8) I ran the game. I noticed that the 2nd profile I made in the game was NOT there and the second batch of ini changes I made were NOT there. I made another profile (call it profile 3) and some ini changes.
9) I switched user back to Helen and ran the game. Profile 3 and the ini changes I made under account Jake were NOT there/applied.
10) This confirmed my suspicions about Virtual Store and about privileges. I went into the Program Files/Holiday Bonus folder and saw that the profile and ini changes I made when the program was first running under hightened user priviliges due to being launched by the installer were in that folder. But all subsequent profiles/ini changes were NOT.
11) I went to Users/Helen/AppData/Local/VirtualStore/Program Files/Holiday Bonus and found a secret little cache of files that Vista had made. The second profile I made when I ran Holiday Bonus separately from the intaller was here and so was a more up to date ini file with more recent changes.
12) Then I swapped users to Jake and looked in the Users/Jake/AppData etc and found the profile I made under that windows account and the ini changes I made too.
13) By the way, I tried going into Program Files/Holiday Bonus/ to manually modify the ini file but it wouldn't let me save it. In fact it wouldn't let me create any files in that folder even though I was logged on as Helen, the original user who has Adminstrator rights.

Uninstall:

- The Uninstall program (also Innosetup) promped for special privileges and then removed desktop icon, quicklaunch icon and folder from program files but it didn't remove the stuff in virtual store. I did this manually for a clean second test.

Second Install:

1) Installed under Helen account. Did NOT auto-launch the game from the installer this time.
2) Ran the game and created a profile and modified ini settings.
3) Checked Program Files/Holiday Bonus and there were No profiles and no ini changes this time because I didn't auto-launch the game from the installer remember? However the profile and the ini changes were found in VirtualStore as was expected.
4) Swapped to Jake account. Surprisingly there was no desktop icon for Holiday Bonus. So desktop and quicklaunch icons are not applied global by my innosetup installer script, perhaps I need a change there. Any advice?
5) Ran the game, it asked me to create a profile (remember there was none in Program Files/Holiday Bonys) and the ini settings were default. Naturally the new profile/ini settings were stored in Virtual Store.
6) I uninstalled the game whilst under the Jake account and was surprised to see that it worked fine and when I went back into Helen's account the game was indeed gone. It still didn't remove the VirtualStore stuff.

So basically if you run a game under one Windows account, Virtual Store works fine. Any files you create when the game is auto-launched by the installer are in the proper Program Files folder, but any subsequent files that the game makes are all stored in VirtualStore, but the game doesn't know any different and works fine.

However, if you swap to another user, they will only see the profiles and ini changes made when the game was launched by the installer and then any more profiles and ini changes that are made are stored under their VirtualStore and because the VirtualStore is NOT global to all users on the PC, if you change users the newest ini settings will not be used and you won't see a full list of player profiles!

This is why we *must* start to use the correct folders, for families that play our games and want to change profiles in-game and compare global highscores etc.

Bit of info on the graphics card. I ran with VSync off and got 80FPS in full-screen and 130FPS in Windowed mode (I guess it's faster because it's drawing to a much smaller area and not having to stretch it? but I'm not sure). OpenGL totally failed - it just gave me a white screen. Weirdly fading in and out with Alpha works, as in the white fades in and out smoothly but there are no graphics! Was disappointed that the Intel card did do OpenGL.

I found a setting in the Intel drivers that made it keep the correct aspect ratio for 800x600 so that it didn't expand to fill the screen. Note that it was off by default so most users will probably see a "fat" game until I code widescreen auto-detection and offer the option to display in the correct aspect ratio (or automaticcaly do that).

Just going to test out OpenAL on my AOTMG demo now...

So Cyg, does this mean it doesn't have it's own RAM, it uses main system RAM instead!? yuk.

OK sound test. Sound is SoundMax Integrated Audio HD whatever the hell that is.

As I've already said FreeAudio is bad.
OpenAL seems totally fine (no lag or breakup), but haven't tested it extensively yet.
Haven't tested DirectSound yet as my framework always auto-switches to OpenAL for Vista.

Yes, the Intel GMA Onboard uses UMA to grab a fixed amount of system RAM for its VRAM.
This is not as bad as it sounds as the inventend technology by intel gives it very good specs, quite near to onboard RAM.

Only problem is the "fixed amount of RAM"

while dedicated cards have AGP apperture, this cards do not have and depending on the system they go as high as 2XX MB and as low as 96MB on Apple MacBooks ...

Ok so they grab a certain amount of RAM as VRAM, hopefully quite a lot.

I've had a look at the saving a file problem on Vista so its visible to all the users on the PC, and can only see on option, regarding the hidden ProgramData folder (Which is located in the root directory)

I tried this:-

Local result = CreateDir("c:\ProgramData\ProjectName")
Local fileout:TStream
If result <> 0
	fileout = WriteFile("c:\ProgramData\ProjectName\test.txt")
Else
	RuntimeError "Cannot write file"
End If

WriteLine(fileout,"Hello")

CloseFile fileout

End

On both Admin/Limited user acounts (Even the guest account) and it worked a charm.

I also read the file from all the accounts using:-

Local filein:TStream = ReadFile("c:\ProgramData\ProjectName\test.txt")

Notify ReadLine(filein)

CloseFile filein

And was happily promted with a Hello from all the accounts

I also had a pop at deleting the file and deleting the folder using the guest account, which appeared to have done the trick when checking the folder on all the accounts.

Is this folder not plausible to throw in your 'global' information, and if not... why?

Dabz

Sounds ECCELLENT if it works on all Vista PCs properly. You have UAC switched on right? I can try this on my "standard" vista laptop when I get back from the Ukraine in 2 weeks. Thanks man.

Yeah, I had UAC enabled! ;)

Dabz

And what do you use to retrieve the ProgramData folder? It's going to be called different things depending on the Windows install language, so you need to get it properly.

I know Gabs mate... I havent looked into it that much TBH, but going off what I've read:-

SHGetKnownFolderPath(FOLDERID_ProgramData,0,pStringOut)

or along them lines! :)

[edit]
Yep, normal CSIDL values have been replaced by KNOWNFOLDERID ones (In Vista).

http://msdn2.microsoft.com/en-us/library/bb407328.aspx

Dabz

FOLDERID_ProgramData being a constant with value $23?

I'm getting a blank string back doing that.

Gabrile have you tried it with another constant to check your extern is working properly? Sorry if that's obvious and you already have.

I downloaded the wrong platform SDK for Windows a few weeks ago, uninstalling it now and downloading the proper one now... Give me a few hours and if I can get it working in Visual Studio using C++, I'll post the code for people to pick over! :)

It cannot be that hard to get it working, surely! :D <--- Famous last words

Dabz

good luck. I expect to get back from the Ukraine to see a full and complete solution posted. Thank you.

Yes sir, and I expect a prezzie from the Ulkraine in return! ;)

Dabz

okok, vodka made from engine oil and chemical fertilizer OK?

Right, sorted... Using Visual C++ Express and the Vista Windows SDK, I've come up with this:-

//ProgramData thing
#include <windows.h>
#include <shlobj.h>
#include <iostream>
#include <stdlib.h>

using namespace std;

int main(void)
{
	HRESULT hr;
	LPWSTR pStringOut = NULL;
	char *folderPath = new char[1000];

	hr = SHGetKnownFolderPath(FOLDERID_ProgramData,0, NULL,&pStringOut);
	
	if ( SUCCEEDED(hr) )
    {
		cout << "Folder found:-\n\n";
		WideCharToMultiByte(CP_ACP, 0, (LPWSTR)pStringOut, -1,folderPath, 1000, NULL, NULL);
		cout << folderPath << "\n";
	}
	system("PAUSE");
}

The whole solution is here to pick over (including an exe):-

http://www.syntaxbomb.com/ftp/dabz/ProgramData.zip

EDIT: Now, I know sod all about MinGW and its inner workings, so if anyone can build on this, great! ;)

Dabz

This works:

?Win32
Extern "win32"
	Function SHGetSpecialFolderLocation(hwndOwner, nFolder, pIdl:Byte  Ptr)
	Function SHGetPathFromIDList( pidList ,lpBuffer:Byte  Ptr)
End Extern
?

Const CSIDL_LOCAL_APPDATA = $1C
Const CSIDL_COMMON_APPDATA = $23

Function GetSpecialFolder:String(folder_id) 
	Local  idl% = CreateBank (8) 
	Local  pathbank:TBank = CreateBank (260) 
	If SHGetSpecialFolderLocation(0,folder_id,BankBuf(idl)) = 0		
		SHGetPathFromIDList PeekInt( idl,0), BankBuf(pathbank)
		Return String.FromCString(pathbank.Buf()) + ""
	EndIf
End Function

CSIDL_COMMON_APPDATA is just a constant with a value of $23. You can give the constant any name you want and the above code is still going to work.

Well I never... great stuff GfK! :D

Looks like you get the vodka made from engine oil and chemical fertilizer! :D

Dabz

[EDIT] oh, and bang that in the archives so it doesnt get lost! ;)

Great so basically we can Auto detect if the OS is vista with some of GfK's previous code and then use that code to write to the common appdata path. I'll test it out when I get back.

OK I thought there might be a hitch, check this:

CSIDL_COMMON_APPDATA 
This folder should be used for application data that is not 
user specific. For example, an application may store a
 spell check dictionary, a database of clip-art or a log
 file in the CSIDL_COMMON_APPDATA folder. This information
 will not roam and is available to anyone using the computer. By default, this location is read-only for normal
 (non-admin, non-power) Users. If an application requires
 normal Users to have write access to an application specific subdirectory
 of CSIDL_COMMON_APPDATA, then the application must explicitly modify the security on that
 sub-directory during application setup. The modified
 security must be documented in the Vendor Questionnaire. 

Sounds like if you are non-admin you won't be able to write to it unless you modify the security settings on the sub-folder. I remember this from before, and that's why Indiepath was using an installer to do it. I think someone esle posted some code to do it but Indiepath said it didn't work...

Dabz, you need to test your code with non-admin users.

Checked, and your right... I read from the guest account, but didnt write! :(

What about CSIDL_COMMON_DOCUMENTS ($2e)????

Will have to check later, going to do a quote!

Dabz

It seems the solution must be to find some code that can set the security settings on the folder BUT it sounds like you can only do that during application setup i.e. when the UAC prompt has come up during the installation and the installer is running under a higher security level.

So if you don't have an installer say, or a portal is wrapping your game, how can you change the security settings on the folder? You probably can't OR you can but each time they run the game it'll come up with the security prompt or something. You could code your game to check if the sub-folder exists and if not, prompt the user just once to boost the security level then create the folder and then for each subsequent play of the game it would be fine and not need to prompt again. God, I feel like I work in CTU in 24 with all this security level stuff! :-o

Okay, I've tried using this without any success:-

http://support.microsoft.com/kb/825751

I've tried using this on the command prompt:-

xcacls.vbs J:\ProgramData /g Dabz-PC\Guest:f /s /l "xcacls.Log"

But, I'm greeted with this:-


Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.

Starting XCACLS.VBS (Version: 5.2) Script at 27/07/2007 19:39:37

Startup directory:
"J:\Users\Guest\Documents\test"

Arguments Used:
Filename = "J:\ProgramData"
/S (All Sub Directories under current directory)
/G (Grant rights)
Dabz-PC\Guest:F
/L (File: "xcacls.Log")

Error -2147024891: occurred in connecting to Local WMI server. (Msg#3302)
Error description: Access is denied.


Operation Complete
Elapsed Time: 0.046875 seconds.

Ending Script at 27/07/2007 19:39:37


By the way, this may not work on Vista and have changed a small selection in the script (Which is pointed out):-

Function IsOSSupported()

    On Error Resume Next

    If debug_on then Call PrintMsg("IsOSSupported: Enter")

    Dim objShell, OSVer
	
    IsOSSupported = False

    Do
	Set objShell = CreateObject("Wscript.Shell")
	OSVer = objShell.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentVersion")
	If blnErrorOccurred(" occurred reading the OS version information from the registry! (Msg#3501)") Then Exit Do

	If debug_on then 
		Call PrintMsg("IsOSSupported: OSVer = " & OSVer)
	End if

	Select Case OSVer
	Case "5.0", "5.1", "5.2" , "6.0"   <---- I've added the "6.0"
		IsOSSupported = True
	Case Else
		Call PrintMsg("")
		Call PrintMsg("************************************************")
etc
etc

Other than that, I'm offically stumped! :/

Dabz

Are we going to decide what to do here or not?

I reckon prompting the user for permsission *in game* to use CSIDL_COMMON_DOCUMENTS with an quick explaination.

Dabz

PS, I may not be able to post as much as I like cos my hands hurt.... so, should we agree with a user enabled 'Blitz' folder @ CSIDL_COMMON_DOCUMENTS or not?

i know its a bit cheeky, but vista is locked tighter than fort knox on a friday night.

advice, this is really important BTW!

Dabz

Ack, all this stuff gives me the heebie jeebies.

Am I correct in thinking that CSIDL_COMMON_DOCUMENTS evaluates to c:\users\public\public documents ?

I've just had a look in there and all I've got installed there is F.E.A.R. which was out long before Vista was about.

yep, thats what i'm thinking...

it is naughty because i personly hate game saves in my doc folder.

but, what options do we have regarding saving data spread across accounts?

Dabz

And I think if Tim cannot suss a way of doing it then what options do we have?

Dabz

I use CSIDL_COMMON_APPDATA, as I reckon this is where you're supposed to be saving such data. I don't really like it when games save their stuff in My Documents or the Shared Documents folder.

The folder permissions need to be set by the installer, unless someone figures out a way to set them in-game. Also, I always make sure the installer is run from an admin account, as I seem to remember having problems when running it from a non-admin account with elevated permissions. It's also a good idea to have the installer install the game for all users.

While googling for something about changing vista folder permissions programatically, I came across this code. I'm a bit busy at the moment, so I thought I'd post if here for anyone who wants to take a look at, and if no one's shown any interest or dismissed it as unhelpful, I'll have a proper look at it tomorrow hopefully.

LPTSTR FileName = "C:\\Temp\\MyDir";
    LPTSTR TrusteeName = "Everyone";

    DWORD AccessMask = GENREIC_READ | GENERIC_WRITE;
    ACCESS_MODE option = GRANT_ACCESS;
    DWORD InheritFlag = CONTAINER_INHERIT_ACE | OBJECT_INHERIT_ACE;    
    EXPLICIT_ACCESS explicitaccess;


    PACL ExistingDacl;
    PACL NewAcl = NULL;
    PSECURITY_DESCRIPTOR psd = NULL;

    DWORD dwError;

    dwError = GetNamedSecurityInfo(
                        FileName,
                        SE_FILE_OBJECT,
                        DACL_SECURITY_INFORMATION,
                        NULL,
                        NULL,
                        &ExistingDacl,
                        NULL,
                        &psd
                        );

    BuildExplicitAccessWithName(
            &explicitaccess,
            TrusteeName,
            AccessMask,
            option,
            InheritFlag
            );

    //
    // add specified access to the object
    //

    dwError = SetEntriesInAcl(
            1,
            &explicitaccess,
            ExistingDacl,
            &NewAcl
            );

    //
    // apply new security to file
    //

    dwError = SetNamedSecurityInfo(
                    FileName,
                    SE_FILE_OBJECT, // object type
                    DACL_SECURITY_INFORMATION,
                    NULL,
                    NULL,
                    NewAcl,
                    NULL
                    );

Dabz, I'm a little unclear on what I'm trying to achieve here, so since you have a non-admin account set up, perhaps you could tell me. ( Or someone else if you can help. )

Can I create the folder ok without permissions or do I need to get permission for that as well before I do it?

For example, on a non-admin account, does this code create the folder?

f FileType("C:\ProgramData\BlitzTest")<>2
	CreateDir("C:\ProgramData\BlitzTest")
	DebugLog "CREATED THE FOLDER"
Else
	DebugLog "THE FOLDER ALREADY EXISTED"
End If

Yes, I know it's not the correct way to do it. I just don't want to write the whole thing until I'm clear on exactly what needs to be done.

This doesn't account for a *file* by that name already existing,nor verifies that a folder was indeed created. (out of disk space? insufficient permissions?)

As I said, I know it's not the correct way to do it. I just want to know if it's possible, with a trailing wind. I suspect it's not, in which case, there's no point me coding up a solution to every possibility until I've solved the first problem.

I'm too noob'ish to help out, but I just wanted to say thanks to everyone trying to come up with a solution. Jeesh, I'm getting a headache from just reading the progress! :)

]
Local result:Int 

If FileType("C:\ProgramData\BlitzTest")<>2
	result = CreateDir("C:\ProgramData\BlitzTest")
	If result = False
		Print "Unable to create folder"
	Else
		Print "Folder created"
	End If 
Else
	Print "The folder exists"
End If

This returns "Unable to create folder" on the guest account.

Though:-

?Win32
Extern "win32"
	Function SHGetSpecialFolderLocation(hwndOwner, nFolder, pIdl:Byte  Ptr)
	Function SHGetPathFromIDList( pidList ,lpBuffer:Byte  Ptr)
End Extern
?

Const CSIDL_LOCAL_APPDATA = $1C
Const CSIDL_COMMON_APPDATA = $23
Const CSIDL_COMMON_DOCUMENTS = $2e
Function GetSpecialFolder:String(folder_id) 
	Local  idl% = CreateBank (8) 
	Local  pathbank:TBank = CreateBank (260) 
	If SHGetSpecialFolderLocation(0,folder_id,BankBuf(idl)) = 0		
		SHGetPathFromIDList PeekInt( idl,0), BankBuf(pathbank)
		Return String.FromCString(pathbank.Buf()) + ""
	EndIf
End Function


Local result:Int 
Local folder:String =  GetSpecialFolder(CSIDL_COMMON_DOCUMENTS)

If FileType(folder+"GlimmerGames Game Profiles")<>2
	result = CreateDir(folder+"GlimmerGames Game Profiles")
	If result = False
		Print "Unable to create folder"
	Else
		Print "Folder created"
	End If 
Else
	Print "The folder exists"
End If

works a charm! :)

I'll have to take a peek at that code you posted earlier, later, i ended up in a scrap on saturday night and still nursing my wounds.

I think I had a dig at someone on here on sunday morning, which I'll find and apologize too, My adrenaline was pumping and was in a foul mood!

Oh well, time to suck it in! :)

Will be back.

Dabz

Well, I've banged that into a simple app:-



And when ran in Guest account it does sod all! :(

I havent went into any real error checking, so it could be out.

Dabz

That code is only supposed to change the folder permissions. You would still need to then create a folder in programdata immediately after that code. I don't have a C compiler set up at the moment, so I'm about 2/3 through converting all that acl stuff into BMax.

I don't have a great deal of faith that it's going to work TBH. If it did, the whole "Vista Security" thing wouldn't have much meat on it. On the other hand, installers must do it somehow, so maybe.

I did attempt to create a folder, still got no access though.

Dabz

Hi. Sorry I was away on Holiday while this whole thread was continuing. So is this a correct summary so far?:

1) Get an installer to make a game folder in CSIDL_COMMON_APPDATA and set the correct permissions. Then any accounts will be able to create shared date in it. JazzieB has hinted that you must run the installer under an administrator account not a normal one with elevated permissions, but we don't have any more detail on this right now. Problems I can see with this approach are a) getting a portal to reliably create and apply the folder permissions in their specialist installers and b) what happens if that installer script is run on XP/98/Me etc, will it still work? Oh and c) ensuring the installer is run under an administrator account if JazzieB is correct. Apart from those issues, it would seem to be fine.

2) Get your game to use code to create a game folder in CSIDL_COMMON_APPDATA and set the correct permissions. Can this be done "silently" (probably not because, as Gabriel says, Vista security wouldn't be much good) or will you have to call some special code which prompts the user with one of those UAC boxes that says the app is requesting a higher security level? Perhaps you won't need special code and the box will appear anyway as soon as you try to change permissions? How has testing on this gone so far? I assume that if the OS is not Vista, we should detect this and simply not call the permission setting code.

3) Use CSIDL_COMMON_DOCUMENTS instead. Am I to understand that all users including non-administrators can write to this fine? If so it sounds a good solution. Only problems are a) some portals may complain that it's not the official location b) some users may niot like it - but stuff them, at least the game works!

I've discounted the LOCAL_APPDATA folder and any others that mean the data is not shared properly between different users logged on.


I'd really appreciate some feedback on this summary because as a group we still need to find the correct way forward. Thanks!

JazzieB: . Why is this by the way? Just to make sure there is a desktop icon and something in the programs menu or some other reason? Thanks.

Yep, pretty much. If the game is only installed for one user initially and a second user wants to manually install it later (by creating their own shortcuts, etc) it will fall over again with permission problems.


I found that running the installer in anything other than an admin account gave the usual problems with files not saving with the correct permissions (basically everything we're trying to avoid) for all accounts.

Also, the installer should still run just fine under any earlier OS under any type of account provided that the ability to install programs hasn't been explicitly disabled for a user or type of account.

As for the portals' installers, I would imagine that they are likely producing installers that set everything up correctly already. It's probably just a case of letting them know where you save your data and what file structure needs to be created. They may insist that you give them this information anyway as a matter of course.

OK thanks. Although if the folder is shared correctly for "all users" (and you don't have to individually name the users) then wouldn't making a shortcut work fine? In fact let's say a brand new user was created after the game was installed, they ought to be able to make a shortcut and it would work. Perhaps I'm missing something about how the permissions work.

Hmm, I should probably test this. The problem is there is no way to ensure that the user installs under an admin account. However, are you saying that when the installer prompts the user for elevated permissions it is NOT the same as when installing under an admin account, that seems strange? Actually I think I recall seeing an app (perhaps it was my installer) ask an actual administrator to logon with a password, I'll have to check this).

Yeah the portals do generally insist on a file "manifest" but not all, and they also get stuff wrong in my experience. Hopefully though, they'll be falling over themselves to do Vista installs "properly"...

Nice bit of info there!

Thanks chaps! :)

Dabz

yeah but still no "official" solution...

I've looked all over too, even on msdn, and it seems they frown on trying to bypass UAC and permissions in code... apparently!

Dabz

Understandably, as the whole point of UAC is that programs aren't supposed to be able to bypass it... :-?

Isn't there a flag or an option within Inno Setup/NSIS/whatever to refuse to install unless the user is admin?

could be, I don't know it that well. I still need to test installing NOT under an admin user to 100% confirm and document what JazzieB is saying. Thing is vista compatibility testing isn't on my to do for 3 more weeks and I can't afford the time right now. I just wanted to get this thread going again and to check my understanding was up to date.

For what it's worth, I would pay to have a module do all of this stuff for me and then I would only have to do something like:

path$ = GetMyAppPath("appname")

Then all I have to do is tag on a file name to path$ when I read/write a file. path$ + "mydata.dat"

The routine would handle all OS situations, etc, do all the grunt work and return the path. ;)

yeah me too. Paying $50 is nothing compared to the time wasted figuring it all out. That's the philosophy behind behind a whole framework too.

But as there isn't a module I'll have to code it myself (if it's even possible) and add it to my framework unless someone posts a solution first...

Agreed, a module would be good value, but it's beginning to look as though it cannot be done outside of the installer.

One begs to ask why MS designed the OS this way.

Grey, if you do add this to the framework I would gladly pay a fee for the upgrade to have this feature.

Have it as a seperate module also as sometimes I only use the timing code from the framwork and not the framework itself.

In my experiece you cannot write into the program files folder anymore unless the exe is 'Running as Administrator'.

You are generally expected to write into the 'Users
\<username>\Documents' or Common (as noted above) folders for application data. The registry can still be used, but is generally not the done thing if it can be avoided.

Don't know it that helps?!



Too many frinkin assholes!

In theory to prevent malicious programs from doing stuff. If one tries to do something naughty, you'll see a UAC prompt (unless you've turned it off) REally we should be blaming the virus and adware writers.

Matt: Yeah, I want to write to a common folder not a user's folder so that highscores can be shared between users.

Here's some more info in different words:

http://msdn2.microsoft.com/en-us/library/aa905330.aspx

But it's saying the same old stuff.

I guess it's possible to embed a "manifest" into your game so that Windows thinks it's an installer and always prompts the user when it loads, and then it'll be able to write into the Common_AppData folder no problems. In fact, thinking about this, it only needs to be able to write into the Common_AppData folder once to make a subfolder for the game and to give it global permissions. Once that subfolder is made the game doesn't need to prompt any more. However, the problem with that is that if you embed a manifest, the only way to remove it is to change the actual exe code somehow!

Would having a UAC prompt appear everytime you run the game be a bad thing? Would it impact sales? Would customers be "worried" by it? If you were already an administrator the prompt would just ask permission. If you were not an administrator then you'd have to logon with administrator password everytime to play the game which would be annoying and in some cases maybe not possible when people aren't supposed to know the admin password.

Why do I want the app to make the sub-folder with special permission in Common_AppData? Couple reasons:

1) if a portal can't make their installer make the sub-folder (or you can't figure out how to make your installer do it) then the game has to be able to do it instead.
2) If you are making a demo and distributing just a .zip file with no installer, you might want the game to be able to do it.

That solution has been floating around in my head for a few weeks now, but its off putting as you mentioned because portals or users may not like it.

So I was floating around with the idea of creating a hidden directory in there that contained all the game info that I need to share amonst users...

If its hidden, it'll not get in anyones way, so there really shouldnt be a problem.

Dabz

You'll have to lie in the docs you provide the portals then about where your app places files ;-)

lol, I'll just say they are saved in a secret place, where me and and my fellow Fraggles can find them....

Seriously though, would portals knock a game back because of this?

Dabz

dunno, a couple have some very "stringent" policies, however if the game's good enough...