Vista compatibility - fuss over nothing?

Hello

Before Vista was released there was a lot of Millenium Bug-esque scaremongering going on, about how none of our games were going to work, because Vista wouldn't let you do this, or that. Well, I've tried it.

User Account Control was left ON (Default) throughout testing.

My game and its installer have been tested in Vista, and everything is working very well.

My program installed itself in the correct location. Shortcuts were properly created on the start menu, and a desktop shortcut. Each launched the game correctly.

My program successfully created a sub-folder containing its configuration files and save game data. It was also able to retrieve data from those files as normal. Vista's user account control displayed NO warnings when this happened.

My only issue has been with sound, but I won't go over that again - there are threads in the Blitzmax section about it. The audio problems were fairly quickly resolved by way of OpenAL.

The uninstaller worked perfectly. User Account Control warned me about running the uninstaller, as expected. All files were properly removed, with the exception of the game folder itself, Data subfolder and contained files. This was expected since these folders and files were created at runtime.

Conclusion: The transition to Vista is going to be far less painful than everybody said it was going to be.

Ahh, but is your account set to Administrator?

I've tested in both.

The only difference, is that when you install/uninstall on a 'standard' account, it prompts for the password of the Administrator account. Since there wasn't one set, just click OK.

The main problems are to do with sharing data across accounts. If you are attempting to write to a shared file (in the shared directory) and you did not create it (in your account) then Vista will block access. However this is only a permissions issue and setting the file permissions to "everyone" will resolve that issue. The same with virtualised directories, virtualisation is done on a per user account basis so whilst your game may well be available to the "installer" it may not function for any other users on that machine.

I haven't even tried Naked War on Vista. Mainly due to not having access to a Vista machine.

Anyone tried it? I seem to remember someone trying it on an early version without problems.

yeah GfK, have you logged on as another user and tried to play the game that was installed under another user? Is that OK?

Tim. How do you set file permissions to "everyone" on a file in code or with an installer?

So sound doesn't work in Vista if you're using Blitz3D then?

The sound works well with Blitz3d in Vista for me ( with generic motherboard sound chip).
I only got some critical problems (in my Blitz 3d projects in Vista) with the "SetBuffer textureBuffer(tex)" and "Cleartexturefilters" commands ( I had to not using them ) and some minor problems with alpha blending colors with my sprite based black smoke effect.
The GPU was a Geforce 7900 GS.

OK, this is interesting...

I installed the game on one account (standard), then created another account and logged into it. I could see the game and run it just fine.

Here's the interesting bit. The game is saving data OK, but each Windows account seems to have its own data files - this isn't ideal.

The plot thickens... the folder where the game is installed to does NOT contain a "Data" folder! Yet when I run the game, my player profile is still there, so the data is clearly being saved somewhere.

Question is.... where??

I've searched all over the hard drive and I haven't been able to locate any of the game's config files.

[edit] Just found it. Users>>Username>>App Data>>Local>>VirtualStore>>Program Files.

Does Vista have an 'All Users' folder under 'Users'?

like XP has 'Documents and Settings>>All Users'

GfK, When a program tries to write to an illegal place, Vista won't moan, it'll just move it into a folder in the users account- Just like you found out. :)

Going back to setting file permissions for a second, you can do so by using SetFileMode <file>,%110110110. This allows read/write access to all three user types (forget what they are, but this also works for Mac and Linux).

As for the virtualisation thing, I haven't had this problem with my tests. My games have saved the high score files in the same folder as the game without any problems. I've checked by physically viewing the Program Files folder in both my normal admin account and a standard account. Pretty sure I've checked with both UAC enabled and disabled. I have yet to work out whether this is something to do with what BlitzMax may be doing when compiling the program, or my installer (I use QSetup).

GFK. OK you've found out what the fuss is about! Basically the virtualisation thing means it detects you trying to write the the game folder and the changes the destination of the writes to the users account folder. However, what confused me is how come BMax knows where to read the data from as Vista wouldn't know the different between a graphic file in the program folder and a data file written by you Unless when it can't find a file, instead of erroring it checks the user folder first ... weird.

Anyway that's why it's better to write and read from the official folders in code I believe.

JazzieB: Thanks.

It's been virtualised to a hidden directory.

Try : c:/Users/[your username]/AppData/Local/VirtualStore/Program Files/Blah Blah Blah

Because Vista virtualises file I/O and even some explorer views - sometimes what you see is not where you think it is.

It really depends on your installer, I'd suggest doing it in code and specifying the permissions when you create the file.

This can be done using the following shell command.

icacls "C:\Users\All Users\Game" /grant Everyone:(D,WDAC)

LOL!, tell that to one of our departments who ordered vista on their machines instead by accident (company standard is still XP SP2)

They had so many niggly little (and big) problems they had to re-negotiate the order and get XP instead.

thanks time so I wonder if that has the same result as JazzieB's code?

Vista permissions are on a per user basis, you have to specify every user who needs access of just use "everyone".

Gfk,

Was yours a BMax or B3D app (I ask as you mention BMax threads with reference to audio)?

I'd like to know a couple of things with regards to B3D and Vista please:

(a) how well does B3d work in Vista andis it easy to set it up manually?

(b) Can I make something autorun on boot up and close it down at the end of the day, automatically - safely?

Any help would be great thanks,

IPete2.

If that was the case, I shouldn't be able to see that high score file in all my accounts. I ran my game in the standard user mode, achieved a score and exited program. Checked file, score there. Switch to my admin account, run the game again, and the previous high score is visible. Shouldn't it have created a new high score table because I'm now in a different account?

If I remember correctly from the doc on MS's site that was linked to on another thread (anyone got that link?), if virtualisation is being used I should not be able to see a file that was created in a different account to the one being used. This was one thing to look out for to see if virtualisation was being used by a program.

EDIT - Link to MS document referred to: http://msdn2.microsoft.com/en-us/library/bb206295.aspx

Have you tried creating score file logged in as admin and then saving a score to it when logged in as a standard account? Your test is inconclusive since Admin has rights to all files.

this gets weirder and weirder!

So Jazzie B, UAC is ON on your PC right?

I've just checked this with UAC ON...

Before turning it off, I deleted the high score and config files for one of my games from the Program Files folder. I then turned UAC ON and reset the PC, as you have to.

Following the reset, I logged into a standard account and played until I got a score high enough for the high score table. I then quit and checked the Program Files folder from the same account. A new high score and config file had been created.

I then logged out of that account and into the admin account (with UAC still ON). The high score and config files were present in the Program Files folder. I double-checked by looking for the virtualisation folder under the Users folder to check nothing was there. Nothing was there! Also ran the game to check it was loading these files and it was.

At this point I then turned UAC off again, reset and logged back into my admin account. I then checked again to see if all files were still present in the Program Files folder and they were.

To conclude, my games are not running in legacy mode, otherwise they would have stored their files in the virtual store under the current user's account (virtualisation is per user only).

It truly is getting weird, as we all seem to be having slightly different experiences here! Also, from the doc linked to above, it should be noted that virtualsation is disabled if UAC is disabled, so any program would probably fail under the new policies. Just goes to show that thorough testing of any game needs to be done under Vista!

My current project is nearing a stage where I'll let it loose to the community for some testing, which I hope will bring some light on this whole matter and ensure that I'm not missing something, but I can't see how when all my tests appear to work!

My tests have all been done from a version of my game installed properly - in other words, I used an installer and didn't just copy the files over to the Program Files dir.


I use SetFileMode on every file I create from within my games to ensure that everyone has access to read and write to these files.

Ok here's the deal.

2 Accounts on Vista : "Admin Account" and "UAC Test"

Test 1:
-------
Login as "UAC Test", create a file in Shared AppData Folder - write some data to it.

Login as "Admin Accout", read file (reading is allowed), add some data and write to disk.

Result : ACCESS DENIED ERROR - File not written.

Test 2:
-------

Other way around, Created file in "Admin Account", blah..

Result : ACCESS DENIED ERROR - File not written.

Test 3:
-------

Changed file permissions to "Everyone"

Result : Read and Write access from both accounts.

####################################################

What about if you apply SetFileMode <file>,%110110110 after you've written/created your file(s)?

I'm doing a generic test, not just good 'old Blitz :)

Surely this would require you to have permissions to change the file permissions in the first place? Seems somewhat prone to failure.

I tried Pervasive 2000i (a database system) with Vista Ultimate - with one machine it worked fine - on my test machine it wouldn't even complete the tests - and thats with UAC off...

V9 works fine though...

What I've discovered today about Windows Vista.

The only way you can install anything, is to have administrator privileges.

If you don't have this, it will ask you for your administrator's password. It then installs the program on the *administrator's* account. By default, InnoSetup will install for all users, but in doing this, each 'standard' account that plays the game will have its own set of configuration files.

I figured it may be better to install for the current user only. Trouble is, as entering an admin password installs the game on the admin account, the standard account you REALLY want the game on, can't see it.

After that I thought it might be best to set the installer to not require admin privileges. But in doing this, the installer simply refused to work - it couldn't create the program subfolder.

Conclusion: I'm at a loss. It seems like the only solution is to let anyone with admin rights install the game (which appears on everyone's account), let anyone play it, but they'll have to put up with having individual configuration files.

Ideally I'd like to be able to save data to a common path. From what I've read (on indiegamer - email from a portal to Grey Alien regarding this issue), it should be possible to do this. Just haven't worked out how, yet.

There's got to be an easier way of life than this programming lark.

Its what makes it 'fun' in a twisted sense,usually,programming involves 10 easy to follow steps:

1) IDEA()
2) STUCK(A_LONG_TIME) 'delay the application
3) BANG_HEAD_OFF_DESK()
4) IF STUCK = BORED THEN GOTO STEP 9
5) IF HEAD = (BALD | GREY) THEN GOTO STEP 1
6) EUREKA:+1
7) IF EUREKA = PROJECT_EUREKA_COUNT THEN GOTO BED
8) GOTO STEP 2
9) REPEAT
10) FOREVER

what does this mean precisely? It doesn't install multiple copies right? You just mean whoeever plays it gets config files (and I presume high score files) made just for them?

Well yeah the email I got and the MS thread about seems to say there is a common data folder you can put stuff in. I guess then you have to make the file accessible for everyone...

Flameduck has a good point. If your game isn't running in adminstrator mode I guess it can't change the file rights to Everyone? This would need testing.

Weird how JazzieB's system it's fine and not on GFK's. Could it be due to different versions of Vista as there are a few? Or maybe it's just down to how it's installed. Maybe JazzieB needs to do Indiepath's generic non-Blitz non-installer test?

Tim. Did you change file persmission with the shell script or by right clicking the file? Also did you do this when in the Admin Account? Would it let you change permissions in the other account I wonder?... So the long and short of your test was that no matter which account you wrote the file in, it could be READ in the other account but not WRITTEN. I'd have assume Admin account could write but obviously that's not the case.

I'll be so pleased when this is done and built into my framework. I'm going to do this:

- Use Shared data folder for ini settings and global high scores, and figure out a way to make it accessible to everyone.
- Use users folder to store their own profile in (for game progress and current score etc). Hmm, mind you I'll need to store a list of available users in the Shared Data folder too...

I started to mess with file permissions when I ran into account issues on the Mac. As I understand it, the program/account creating the file has the necessary permissions to change them. This solved my problem on the Mac (and Linux), and seems to be avoiding issues on Vista.

Also, as GFK pointed out, you do need to have the installer of the app run from an admin account and have it install for all users. Otherwise it will just fall over in any number of places. I went through similar pains when I first checked through all my back catalogue.


You can retrieve most of the special folders you'll need via the environment variables. Type 'set' at a command prompt for a list of them and you'll soon see which you'll need. There's also some code in the Win32 forum for finding other special folders.

Maybe I'm just being ignorant of others experiences here, but I've had none of this trouble and have not found a need to make use of the 'proper' folders so far. I did actually prepare code to make use of them before I got Vista, but then found it wasn't as big a deal as I thought it would be. Or maybe it is, but I'll thoroughly check this out before release.


I checked the file properties after the file was created in a standard account and Everyone was enabled for read/write permissions.


I'm using the Ultimate edition, but surely UAC and permissions should work the same no matter what version is being used. There's no mention in that MS link that indicates this. As for the non-installer test, I don't think it's really necessary, as the end-user will always be using an installer. It would be interesting to see what happens if the files are just copied into the Program Files folder though.

I'll be glad when we get to the bottom of this and find a definitive right way of doing things.

12 hours later:

"You are coming to a sad realization: Cancel or Allow?" ;)
http://www.youtube.com/watch?v=FxOIebkmrqs

More seriously, I thank you and the others in this thread for exploring these problems and sharing the results. Sooner or later Vista will probably become the dominant version of Windows, so these security issues will need to be dealt with by Blitzers wishing to sell games or even distribute freeware. I gratefully look forward to reading about everyone's continued progress.

I've just cobbled this together from bits of code here, and some stuff from MSDN.

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

Const CSIDL_DESKTOP = $0
Const CSIDL_INTERNET = $1
Const CSIDL_PROGRAMS = $2
Const CSIDL_CONTROLS = $3
Const CSIDL_PRINTERS = $4
Const CSIDL_PERSONAL = $5
Const CSIDL_FAVORITES = $6
Const CSIDL_STARTUP = $7
Const CSIDL_RECENT = $8
Const CSIDL_SENDTO = $9
Const CSIDL_BITBUCKET = $A
Const CSIDL_STARTMENU = $B
Const CSIDL_DESKTOPDIRECTORY = $10
Const CSIDL_DRIVES = $11
Const CSIDL_NETWORK = $12
Const CSIDL_NETHOOD = $13
Const CSIDL_FONTS = $14
Const CSIDL_TEMPLATES = $15
Const CSIDL_COMMON_STARTMENU = $16
Const CSIDL_COMMON_PROGRAMS = $17
Const CSIDL_COMMON_STARTUP = $18
Const CSIDL_COMMON_DESKTOPDIRECTORY = $19
Const CSIDL_APPDATA = $1A
Const CSIDL_PRINTHOOD = $1B
Const CSIDL_LOCAL_APPDATA = $1C
Const CSIDL_ALTSTARTUP = $1D
Const CSIDL_COMMON_ALTSTARTUP = $1E
Const CSIDL_COMMON_FAVORITES = $1F
Const CSIDL_INTERNET_CACHE = $20
Const CSIDL_COOKIES = $21
Const CSIDL_HISTORY = $22
Const CSIDL_COMMON_APPDATA = $23

Print GetSpecialFolder(CSIDL_LOCAL_APPDATA)

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

Credit to whoever wrote the bits I borrowed from here. I can't remember who you are, though.

I'm not sure if CSIDL_LOCAL_APPDATA is the one I need for Vista, but at least the above code is returning results that *seem* correct. I'll play more tomorrow.

[quote]I'll be glad when we get to the bottom of this and find a definitive right way of doing things. [/quoteme three!

WendellM: lol @ video and "sad realisation" ... "allow"

GfK: Hmm so there is:

Const CSIDL_APPDATA = $1A
Const CSIDL_LOCAL_APPDATA = $1C
Const CSIDL_COMMON_APPDATA = $23

Wonder what the difference is?

When I do the set command on XP I see:

ALLUSERSPROFILES=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\Jake Birkett\Application Data
CommonProgramFiles=C:\Program Files\Common Files
HOMEPATH=C:\Documents and Settings\Jake Birkett\
USERPROFILE=C:\Documents and Settings\Jake Birkett\

And that's it in terms of useful paths.

Reading that MSDN doc again it seems to say that you should use:

CSIDL_LOCAL_APPDATA C:\Users\user name\AppData\Local

To store user-specific data such as save game and any player specific configuration preferences.

CSIDL_COMMON_APPDATA C:\ProgramData

To create game data that cn be read by everone e.g. high scores and global config BUT it says that only the original user can WRITE to it. So this must be where setting the file to EVERYONE comes in.

Also what I want to know is do these CSIDL consts/paths work in XP and 2000 (probably), and also do they work in 98/ME or do they return Null or something?

SHGetSpecialFolderLocation, according to MSDN, is compatible with Windows98. I read somewhere (probably on MSDN too) that the constants are the same, too.

I'm running XP and tested about half a dozen of these, everything returned the expected path.

I don't think we can expect the end-user to know or even be inclined to start messing about setting access permissions, therefore I don't think CSIDL_COMMON_APPDATA is the way to go on this. Unless there's some way of doing it programatically, which I doubt. Anybody tested SetFileMode yet?

OK so SHGetSpecialFolderLocation works on 98, I just hope that the same constants all exist.

As for not using Common_AppData then where will you put a High Score table that can be written and read by everyone? I think you are supposed to put it there and use JazzieB's permissions code, OR I guess create an empty high-score table and use an installer script that does it for you. But I'd rather make the high score and settings files the first time the game is run and set the permissions then. This ensures that if portals package your game it will work and they don't need to do anything unusual with the installer (i.e. time wasted by both parties)

Btw, for JazzyB, from MSDN "Virtualization will be removed from subsequent versions of Windows so it important not to rely on this feature"

Also "Note that if UAC is disabled, then virtualization is also disabled. If virtualization is disabled, standard user accounts behave exactly like limited user accounts in Windows XP, and legacy applications may not function correctly for standard users that would otherwise have succeeded due to virtualization."

Basically the new methods need to be embraced, sigh.

Also there's this whole "Application Manifest" issue. And that if you make one of those and declare your app's execution level in it, then Vista won't use Virtualisation. But what the hell is an Application Manifest and how do you make it anyway. Perhaps BMax should make one by default now?

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

Thread1: http://forums.indiegamer.com/showthread.php?t=9781

Also: http://msdn.microsoft.com/msdnmag/issues/07/01/uac/

In that third article it says:

"Sometimes, as when you're storing high scores for a game, you need to maintain system-wide state and allow users to write to it. The recommended place to store this data is in the %allusersprofile% directory. Here you can create a directory specific to your application and allow users to write to it. Just remember, other users can tamper with this file."

Does this mean that if you put a file in allusersprofile as an administrator, that a standard user can a) read it and more importantly b) WRITE to it? (i.e. without running any code to sett access to EVERYONE)

Tim and GFK: Perhaps you could test the above manually by making a text file in the all users folder and then changing user and trying to write to it?

It also says this about user preferences/settings:

"When you design your application, there will likely be some application settings you'll want applied for the user. Perhaps the users specify custom information about how their views are shown or which menus are displayed. A good way to provide this facility is to create a default template under the Program Files directory, then copy and modify it in the user's AppData directory, %local­appdata%. This data can be copied at first run of your application and enables per-user state for each user. If, on the other hand, you want machine-wide state that individual users can modify, you would want to put this in the %allusersprofile%, as in the high scores example mentioned earlier."

So localappdata is best for user save games etc like you said GfK.

Some we are getting somewhere ...

so Ironic the title of this thread :-D

So I guess by now you're thinking, that the BlitzMAX documentation is starting to look pretty good, right?

All Users is a Virtual folder that is implemented for legacy support. Writing to All Users will be virtualised, the actual write goes to Program Data and guess what.... Problem solved.

I'm aware of this. What I can't get my head around is that my games don't appear to be using any type of virtualisation anyway, which have been tested with UAC on and in two user accounts. I can see the files created from a different account, which I should not be able to do as virtualisation is per user only, so any files would be stored in the virtual store of the user that created them. Swapping accounts would then seem to make those files disappear and the game would then recreate them for the new user. This isn't happening in my case, and I can freely read and write to those same files for both of my accounts, even when created from another account.

I'm kind of glad I have a week off coming up, as it will give me plenty of time to get a test version out and plenty of testing done.

JazzieB: Are you sure you are not using your XP Pro machine instead of the Vista one? ;-) kidding. It's one helluva weird thing going on on your PC.

Tim: Sorry, so to clarify, If you go to Program Data and make a text file in one profile, the other profile can read AND WRITE to it yes?

So basically it's safe to use the AllUsers path for high scores/settings, but what is the CSIDL for it? Is it this one: Const CSIDL_COMMON_APPDATA = $23 ? I can't really tell as I'm working blind in XP.

Perhaps someone with Vista can type SET at the command prompt and see what values you get for these environment variables and any other interesting ones (these are my XP values):

ALLUSERSPROFILES=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\Jake Birkett\Application Data
CommonProgramFiles=C:\Program Files\Common Files
HOMEPATH=C:\Documents and Settings\Jake Birkett\
USERPROFILE=C:\Documents and Settings\Jake Birkett\

Thanks.

***
Hey if All Users (ProgramData) is safe for all standard/admin file reading/writing then why even bother to store player profile info (current level/score etc) in some special Local user folder? It might as well all go in Program Data.

To improve usability in multi-user systems? So that instead of the game asking you which profile to load, it just loads the profile for whatever user is logged on?

I guess so. Problem is then what if someone else wants to swap to their player profile without logging onto Vista again? You'd have to store a list of possible profiles in a GLOBAL location to know what other profiles the player could choose and then you'd have to find them in the correct place, which might not be so easy...

No that is not correct, if you go direct to Program Data and make a file then it will have the normal restrictions. If you write to ALLUSERSPROFILE/mydata then Vista will write the file to Program Data BUT it will give the files nice sharing permissions :D

Ah OK, thanks for the clarification!

Why on earth would you want to do that?

eh? Imagine I'm logged onto vista and I've been playing a game then my son wants a go in his own player profile (this happens all the time). So he would just want to change player in the game, not come out of the game and logon to vista with his own windows profile so that his player profile could be read from the correct "local user data" folder, that would be lame. Am I missing something or are you?

Fast User Switching?

Fast user switching would still mean having to log-off/out and then having to log in again. Plus, if the game was left running in the other account, wouldn't most of the game files be locked if they were still in use, or not kept in sync if your game only updates high score files and such-like when the game is exited, with one overwriting the updates of the other.

It's far, far simpler just to allow a user to switch a profile within the game itself. Every other game does this. Also, not everyone may have an account on the PC it's being played on, e.g. having friends round, etc.

*if* you use that... Back when I still had just a single PC, we just shared a single account. The only 'personal' settings where the email, and that was a non-issue since we used different email clients.

I'm with Grey on this one.

Instead of arguing about WHY we're doing it, perhaps we should get back to discussing HOW we're going to do it?

That's what we're all interested in at the end of the day.

well here's my summary. I'm going to use one path only: ALLUSERSDATA or whatever, need to find the CSIDL for this. This will put the files in a folder where they can be read and written to by all users I believe (I still need to personally test this)

In here I'm going to store a global high score, a global settings file, then a folder with the player profiles in (this will enabled me to show them in a list and let the player choose a profile - like normal in other words!)

That's it! No permissions code required. No fancy installer stuff (all those files will be generated by the game dynamically)

Its apparently CSIDL_COMMON_APPDATA according to MSDN.

However, other information contradicts this. While claiming that this is the best place to store such data, the thread below also confirms (in Vista RC1 at least) that documents saved in CSIDL_COMMON_DATA are only writeable by the file creator.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1184563&SiteID=1

Now, what's interesting is this link: http://msdn2.microsoft.com/en-us/library/ms995853.aspx


One would assume that if its possible to have an installer modify file/folder permissions, then its equally possible to do it programatically at runtime.

This being the case then all that needs to be done, is that each time we create a file, the first thing to do in each and every case is to modify its permissions via SetFileMode.

If this works, problem is solved. If not..... I dunno. Perhaps there's some way of creating a program data folder at setup time via InnoSetup, give it the right permissions there, and I would expect any files that are created within that folder to have its permissions inherited.

I just use :

char * safePath = new char[MAX_PATH];
GetEnvironmentVariable ("ALLUSERSPROFILE", safePath, MAX_PATH);

This will actually write to APPDATA with the permissions already set for sharing.

Hmm the plot thickens. Like I said I haven't tested this, I was going on what Tim said when he said it works, and I believe him, but there may be more to it...

Assuming that does work (and I have no reason to think it doesn't), surely returning the same path via SHGetSpecialFolderLocation would yield identical results?

I'd much rather avoid reliance on environment variables. I don't know why. Personal preference I suppose.

I'll have a play around with this later and hopefully come up with something useful thats been tested under Vista.

Yeah I'd rather use SHGetSpecialFolderLocation too, so the CSIDL is CSIDL_COMMON_APPDATA right. OK. Be interested to hear your results.

OK I'm testing this in XP just now, and already I'm not getting expected results.

env var ALLUSERSPROFILE = C:\Documents and Settings\All Users
CSIDL_COMMON_APPDATA = C:\Documents and Settings\All Users\Application Data\

I kind of expected to get the same result for both.

Looking at C:\Documents and Settings\All Users, this isn't really a good place to be storing game data. Nothing else does - every other app puts it in \Application data (hidden folder).

Tim - can you clarify if you're writing data directly into \All Users, or manually adding an "\Application Data" suffix to the returned path?

Interesting, thansk for the heads up. Adding application data to the path may not be very good for Vista... Seems that the CSIDL is the way to go.

Adding "Application Data" on the end of a file path is never a good idea for the same reading that you should not add "My Documents" on the end, as it may not be called that in a version of Windows with a language other than English. It may also change in the future (they changed between XP and Vista remember).

Also ALLUSERSPROFILE is only meant to point to the root of the All Users folder and has nothing to do with application data. That's why COMMON_APPDATA returns a path that includes the Application Data folder.

I'm not sure I want to be storing files in a hidden folder anyway. My next game will have a level editor and it wouldn't be good storing them in a hidden folder, because the user may want to email them to their friends. Then again, it's not ideal sticking them in the Program Files folder either. But that's another issue altogether, which I'll deal with when the time comes.

For a situation like that you could save it into the "My Documents" (or whatever the Vista equivalent is called) with CSIDL_PERSONAL.

yep, same with screenshots.

Sorry about this - I'm actually not going to be able to get this tested under Vista until at least tomorrow. Feeling a bit under the weather today.

I'll post results here as soon as there's something to tell.

It going 'round, I think. I've been suffering from a stinking cold (aka man flu) for the last couple of days. :(

Same :/

Me too for like 3 months, I finally feel great this week all except for my nose which is seeming to react to spring.

Right, had a play with Vista again today.

Afraid there is bad news.

I created a text file (from within Blitzmax) with one account, and attempted to access it from another. I can read the file OK, but I cannot write to it.

Using SetFileMode file,%110110110 made no difference. Upon using FileMode to determine which bits were already set when the file was created, it was already set to %110110110.

Further, attempting to write to these files, caused Vista to get all clever, and it saved my files to the VirtualStore instead.

I'm at a loss now, and open to suggestions.

Hmm. Maybe first determine if the file is writeable, as you've already done, then if it isn't, make a copy of the file and name it incrementally. Have your game only use the most recent file and also attempt some kind of housekeeping to delete any old files it has permission for.

A bit messy and hacky I know, but it's the only thing that springs to mind at the mo. :P

Problem is, if it can't open a file (via WriteFile) in the Application Data folder, it opens it in the VirtualStore instead.

You have no way of knowing where the file will be. All you know is that the file has been opened.

There has to be some way around this...

Oh, I see. All this Vista file shenanigans is making my head hurt, TBH. :)

I just checked out the environment variable thing in Vista. It returns a completely different path!

Strict

Extern "Win32"
	Function GetEnvironmentVariable(lpName$z, lpBuffer:Byte Ptr, nSize) = "GetEnvironmentVariableA@12"
End Extern

Print GetEnv("ALLUSERSPROFILE")

End

Function GetEnv$(envVar$)
		Local buff@[64]
		
		Local rtn = GetEnvironmentVariable(envVar$, buff@, buff.length)
		If rtn > buff.length
			buff@ = buff@[..rtn]
			rtn = GetEnvironmentVariable(envVar$, buff@, buff.length)
		EndIf
		
		Return string.FromBytes(buff@, rtn)
End Function

Result: "C:\ProgramData"

in Windows XP, the same code results in "C:\Documents and Settings\All Users", which as I said further up, is not a good place to be storing stuff.

Seems I was wrong about where ALLUSERSPROFILE points to. Doesn't make sense to me that it points to a common application data folder rather than a location of an All Users profile!

Anyhow, under Vista there is a PUBLIC env variable that does point to an All Users folder. Not sure if that's of any more use to you.

Having had a peek at the ProgramData folder, it does appear as though that's the way it's supposed to be done, but I'd rather not have the data hidden, as I'd like a user to have quick access to any levels they may have created, and so on.

We may have to give up and do things MS's way, even if it is a royal pain in the backside. Although I'm about ready to package the current build of my game up for overall testing and to see how things work on the Vista front. Keep an eye on the Showcase forum.

Right - solution!

I've completely changed my angle of attack on this one. I figure that if we aren't able to modify user permissions programatically (for whatever reason), then another way might be to do it at install time.

In InnoSetup, its simply a case of adding the following to the script (I put it below the [Tasks] section, don't think it matters though):

[Dirs]
Name: "{commonappdata}\Your Company Name\Your Game Title"; Permissions: everyone-modify

In Vista, this creates a folder at "C:\ProgramData\Your Company Name\Your Game Title\". Permissions are set to 'everyone', and all users can create/read/write/modify anything in that folder, since permissions for all created files are inherited from the parent folder.

[edit] If your users might need to delete files too, then non-owners will need full access instead:

[Dirs]
Name: "{commonappdata}\Your Company Name\Your Game Title"; Permissions: everyone-full

[/edit]

Also tested this under XP and all is well.

From Blitzmax, use the code below to find the common application data path, then tack your company name and game title onto the end, so that you're accessing the same folder which your installer created:

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


Const CSIDL_COMMON_APPDATA = $23

Company:string = "Games Company"
Title:string = "Game Title"

Global dataPath:string = GetSpecialFolder(CSIDL_COMMON_APPDATA) + Company + "" + Title + ""

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

EXCELLENT work! That's the solution I'll be using. Thanks. Mind if I put this in the framework and credit you?

Nope, knock yourself out.

[edit] You might want to include the other CSIDL constants from the post above if you want to make it more 'complete'.

Yeah I may as well. thanks man.

Hmm just a thought, this approach will only work for my own games sold on my own site where I have a control of the install process. If I sell my games on a portal I'll have to tell them to make sure their install makes the folder with those permissions, which could be a fag and also error prone.

Thing is, surely if an installer can make that path with those permissions then surely a Blitmax program can? Unless the installer can only set those permissions because it has elevated permissions already?

So for me, I still need to do more research.

Yeah, that's true. But I don't think the buck stops solely with the developer when it comes to compatibility. Its quite a small measure for them to take to ensure compatibility.

Just discussing the exact same thing on IRC with somebody. Ideally I'd like to do it that way, but creating a data folder via InnoSetup will do for me, for now.

At the end of the day it requires zero maintenance by the end user, which is a good thing.

SetFileSecurity().

Wonder if this is what we're looking for? Unfortunately I just glazed over when it started going on about SECURITY_DESCRIPTOR structs.

Anybody?

Just built the latest version of my project and left it with it's data folders in Program Files. Turned UAC on before running the installer and tested. Everything still works fine for me, with all accounts having access to all files for read/write permissons.

I do agree though, that the installer needs to be set up correctly, i.e. installing for all users and ran from an admin account.

I suppose we should be using the ProgramData folder, as it's the proper way of doing things, and I may well alter my project to do this before release.

I'm in the process of uploading my project for overall testing by the community and not just for any Vista issues. I'll post a link to the thread once I have created it.

Well... I've fannied about with this for the best part of a day now and, pertaining to file and folder permissions from Blitzmax, I've got absolutely nowhere.

I think I'm going to run with letting the installer set folder permissions. I really don't consider this a big deal anyway. As long as the permissions are set properly, it doesn't really matter when its done.

If a BlitzMax solution comes along in the coming months, then I'd probably use that instead.

I might have to post about this over on Indiegamer at some point...

Was thinking the same. It isn't just Blitzmax this affects.

yeah if someone has some C code to set the permissions we can use that.

Ok, I've now uploaded my project for a thorough thrashing by the good folk here. If you want to give it a whirl and test it for Vista compatibility then the thread is here. Seems to work on my system, so I'm curious if it falls over on others (I hope not!!).

Tim posted a way to change permissions here:

http://forums.indiegamer.com/showthread.php?t=10111

I'm not convinced this is the best method of doing it, though.

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

Ahh, so it was down to the installer all along. Guess we'll start to see an end to distributing software via ZIP for those that know how to use them.

Bloody 'eck. Think I might go back to console dev and leave PCs alone. What a palaver. This is all for 'security reasons', right? The cure seems worse than the symptoms - for devs, at least. :/

GfK: Yeah but you could call "during application setup" as the first run of your app...

Yeah, I didn't quite get what they meant by that term.

Maybe, but provided the permissions are correctly set, does it matter if its done during 'setup', or at the first run? And besides, I'd be more inclined to refer to running a program as 'application startup', not setup.

Not really. People who prefer their games by ZIP file generally wouldn't expect to be able to use them across a multi user environment without modification. And even if they did want to do that, they can always manually set permissions.

The whole point of this thread has been to come up with a way of packaging software in such a way that it requires minimal effort for customers to get it up and running.

The older, more long-winded methods will still be valid.

It's actually for "lack of security reasons".

So how do roaming profiles fit into this whole thing?

Erm, just for anyone that doesnt realise, Vista is a completely new OS, its not XP, and trying to be the most secure OS it means that US developers have to change the way we program things...

live with it, or use a different OS

like mini3d,use it, or something else.... WE KNOW

Right.

Program once, run on any trash OS won't work anymore.
Working on Vista most likely is done at best through a .NET capable language (hopefully BM will learn that end, it learned Cocoa as well to fit in Apples plot) as it is based around that and the vista successor in 2011 will fully base on it.
So thinking of .NET as the great evil is something you can only afford as pingu or apple fan, but not if you intend to work on windows platforms any further. (would be as stupid as thinking that cocoa is a bad thing and planning to work on OSX)

I suspect you've completely missed the point. 'Living with it' is precisely what we are trying to do. Whatever your motivation for jumping in and hurling abuse, you should probably shut up and bugger off, or say something useful. Personally I'd prefer that you just buggered off if your only intention is to start trolling and derailing threads which exist for the benefit of the damn community. :/

....and for those of us who only speak English...?

"Program once, run on any trash OS won't work anymore."

How is it advancement when you cant write for windows now and expect a program to run on windows? seems like a retarded step backwards to me.

You're wrong on both accounts. Vista is not a new OS (it was supposed to, but after four years of little to no progress, they decided to drop that idea). Secondly Vista is not trying to be more secure, it is shifting responsibility for being secure onto the users. As this thread has unquestionably demonstrated by now there is precious little developers can do about it.

Clearly you haven't actually tried that.

You've never really been able to do that. If you can get a program to run across the 5 most widely used flavors of Windows, you should wear the right on your sleeve - probably put that on your CV.

erm, im just putting my point across.Is that a bad thing?

I'm not trolling anything by the way, I've tried a few languages and one language i really liked was blitzmax, so im very very very sorry i dont have the same thoughts as you, and im very very very sorry that youve sold 13+ games to my 0- ones...

I came here as being part of COMMUNITY,so if i have completely missed the point, does that mean im subject to any sort of abuse... as far as i can see, ive said nothing to influence any reaction like youve suggested, please, post links that suggests ive ripped you and every blitzmax member apart... be my guest

[edit]
And I've paid exactly the same amount as you for BlitzMax, so who the HELL are you to tell me to bugger off?

Oh.... you're Dabz??

hello, sorry. Didn't realise it was you. Thought you were some know-it-all Johnny-come-lately.

never judge a book by the cover! :)

Dabz

I don't do books. ;)

Why the name change?

well, I was intriged by the way some users would come on the forums and get heckled!

Basically, they are good people, with different views... why bother them?

I love Blitz by the way, theres probably no bigger fan, but I just hated when joe user would ask a normal 'Blitzcoder' style question and just get ripped to bits because of it!

No one IMO is better than anyone else, and no language is better than the other... If I think Blitzmax is pap, thats my OP, though, the only reason I dislike BM is the IDE... nothing more...

I never meant to be funny being an alias, I just wanted to know wha6t the average new user has to put up with when trying Blitz... And its not very good, sorry to say, I mean, I put BM in PC Format in the readers pages for gods sake... doesnt that mean anything! :)

Anyway, I just wanted to know, now I know... I never bothered you Gfk in my posts as Evamp, so... why the 'bugger off'

And I mean that in the nicest of sense, I'm just intrigued?

Dabz

^^^that.

Allow me to elaborate. I've spent the best part of a week, on and off, trying to get this sorted out for the benefit of everyone.

The comment you made, to me, seemed to dismiss the whole thing as a non-issue. While for people who are currently developing games, its an issue of high importance, as anybody who gets a new PC from PC World or wherever from now until God knows when, is likely going to have Vista on it.

Its therefore imperative that our games work - if they don't, we'll likely spend the rest of our days answering one support email after another and not getting any more dev work done. Which is why I've been busting my ass trying to make sense of Vista's over-enthusiastic security. It needs doing. It isn't a case of "use another OS if you don't like it". Two years from now most people will be using Vista. It MUST be supported, as awkward as it is.

Your right, i just needed to know :-]

To be honest, I 100% respect your work, and wasnt trying to be funny or anything, but you know how these things grab you! :) *Surely someone will post 'no I dont' lol*

The Blitz community had a funny turn IMO... it probably started with my BMax V DB thread, but sod it... I'm a programmer, who gives a flying F what I prefer, I just want to program at the end of the day! :)

Oh, and Vista rules by the way! :D

Dabz

P.S. http://www.syntaxbomb.com/forum/index.php?topic=501.msg3647;topicseen#new

Just in case you dont beleive me lol

Aah so you are EVamp. OK.

stop kissing each others asses and fix this

It is fixed, sort of. At least we now pretty much know what we need to do. Basically...

1) The installer needs to be run from an admin account and install for all users, making sure that permissions are set for all users on any files/folders it creates. Usually, a little check-box that says "install for all users" is all that needs to be done, or a switch if it's a scripted installer. May vary slightly depending on the installer being used.

2) Any files/folders that are created by the program should have their permissions set to all users by using SetFileMode <file>,%110110110 after they have been written.

3) Although I've found this not to be necessary, the correct place to store your app's data is the ProgramData folder (which is hidden). User specific data can be stored in the user's own folder. There are API calls to retrieve the location of these folders (as discussed above and in the Win32 forum).

I've found that as long as the permissions are set up correctly, you can still store data in the program's own folder. This isn't the 'correct' way of doing things, according to MS, but everyone's been doing it for years and it was never the correct way! Probbably should do it right, and I may well change to do it this way at a later stage.

GfK said the SetFileMode thing didn't make any difference...

Maybe, but it does make a difference on the Mac. That's why I started to use it in the first place, and why I'm not taking any chances with Vista. Anyway, I won't go into Mac issues here, as this is about Vista. At least the rest of what I've said holds true, I think!

Oh oK, thanks for the clarification.

This C code might help

bool CgeneralFuncs::CreateDirectoryUserFullAccess(LPCTSTR lpPath)
{
	int f = CreateDirectory(lpPath,NULL);
	if(!f)
		return false;
	
	HANDLE hDir = CreateFile(lpPath,READ_CONTROL|WRITE_DAC,0,NULL,OPEN_EXISTING,FILE_FLAG_BACKUP_SEMANTICS,NULL);
	if(hDir == INVALID_HANDLE_VALUE)
		return true;
	
	ACL* pOldDACL=NULL;
	SECURITY_DESCRIPTOR* pSD = NULL;
	GetSecurityInfo(hDir,SE_FILE_OBJECT,DACL_SECURITY_INFORMATION,NULL,NULL,&pOldDACL,NULL,(void**)&pSD);
	
	EXPLICIT_ACCESS ea={0};
	ea.grfAccessMode = GRANT_ACCESS;
	ea.grfAccessPermissions = GENERIC_ALL;
	ea.grfInheritance = CONTAINER_INHERIT_ACE|OBJECT_INHERIT_ACE;
	ea.Trustee.TrusteeType = TRUSTEE_IS_GROUP;
	ea.Trustee.TrusteeForm = TRUSTEE_IS_NAME;
	ea.Trustee.ptstrName = TEXT("Users");
	
	ACL* pNewDACL = NULL;
	SetEntriesInAcl(1,&ea,pOldDACL,&pNewDACL);
	
	SetSecurityInfo(hDir,SE_FILE_OBJECT,DACL_SECURITY_INFORMATION,NULL,NULL,pNewDACL,NULL);
	
	LocalFree(pSD);
	LocalFree(pNewDACL);
	CloseHandle(hDir);
	return true;
}

Sounds pretty cool, could be what we are looking for. Now for anyone to convert to Bmax :-) I can test it on vista then.

Isnt that the crux of all past problems with windows in general.. that user installed programs are not tied to their 'owners' file-permissions?

If vista has taken this ability away (that normal users can install shared programs) then that is at least one good idea in a whole OS full of bad ones.

Its good to know that blitz stuff is working with fewer problems than anticipated though :)

It probably ISN'T OK under vista which is why I asked. I haven't got round to testing yet, but will very soon.

Oops sorry :)
I get what you are saying now. It will be interesting to see what happens with this and weather vista is *really* more permissions based or if its just a glorified app-in-the-middle hack job.
Since switching (90%) to an OS with UNIX permissions I can really see the extrordinary advantage of such a good FS design. I was kind of hoping MS would have come up with something similar to this for vista. Problem is its so 'pretty' looking its hard to tell where to look to get this information (eg how do i get the equiv of: DRWXR-XR-- or something else that tells me simply who owns what)

I'm not really an expert on file permissions etc, I get the idea but don't know the details. It's something that's never been that important to me (or my IT clients!)

The code I posted was developed specifically to address the vista security issues - I've only used it on CSIDL_COMMON_APPDATA and it works even via a plugin in IE7 protected mode.

sounds ACE as that's the path I want to use it on too (well a sub-path of that, I assume that's what you mean). As long as I can find out all those constants it should be possible in Bmax. Just hopeing someone will be me too it, or have you made this into a C++ dll that can be called?