Windows game high scores not saved

Something possessed me to install Snood on the kids' computer again. That's a great, little game. (If you want the same basic game in FreeBSD, take a look at "games/frozenbubble" or "games/monkeybubble" in ports.)

But, after a day of play, we noticed something horrible. Most high scores were not being saved! I've had this issue before with some other Windows games so it was no great mystery. On the kids' Windows XP, only I have administrative rights.* So, after I installed the game, the high scores file (whatever and wherever that was) was only writable by me. When they log in and play, their high scores are not saved.

So, let's fix this. As far as I know, this must be done via the command-line. (I'm doing all of this in XP, BTW. If you're running another version of Windows I don't know which parts of this will work, if any.) Open the "Command Prompt," found under "All Programs> Accessories" in the Windows menu.

Next, you've got to find the file where the high scores are saved. This is not necessarily as hard as it sounds. In the case at hand, I've played and saved a high score successfully, so the file in question should have a modification time that is later than any other file. I've installed the game in the directory "C:\Program Files\games\Snood 4" and if I "cd" there and then run "dir /o:d", I can easily see that "SnoodPrf.40W" is that file:

C:\Program Files\games\Snood 4>dir /o:d
Volume in drive C is SOMETHING
Volume Serial Number is    X-YYYY

Directory of C:\Program Files\games\Snood 4

11/08/2001  03:27 AM           237,568 glut32.dll
07/31/2006  02:14 AM            38,928 Agency.fnt
08/08/2006  09:31 AM             6,022 HelpLB.txt
05/18/2007  12:41 AM           268,304 Lexia.fnt
01/22/2008  03:31 AM            77,204 Snood 4.0 ReadMe.rtf
03/15/2008  05:04 PM        18,182,144 Snood.exe
05/22/2008  12:37 AM           685,849 unins000.exe
05/22/2008  12:38 AM             2,332 unins000.dat
05/24/2008  08:40 PM    <dir>          .
05/24/2008  08:40 PM    <dir>          ..
05/24/2008  08:40 PM            10,820 SnoodPrf.40W
    9 File(s)     19,509,171 bytes
    2 Dir(s)  80,384,868,352 bytes free

Now for the fun part. We'll need to use the little known Windows program "cacls" to make that file world "changeable". Use some care with this utility. First, run "cacls /?" to see the basic usage. Of special note, always (always) use the "/E" switch so that your changes to the file ACLs don't replace ALL of the existing ACLs. (Yes, it's stupid by default.) Next, just run "cacls <file-of-interest>" to see what the existing ACLs are. There are several in most cases (and if you forget the "/e" switch, you'll have to replace them all, so be careful).

In my case, I can see that what I want is for the unprivileged "BUILTIN\Users" to change from "R" (read access) to "C" (change access). I say "in my case," only because some people may have a more complicated set-up with network users -- but I'd expect the vast majority of people to be in the same boat as myself. So, here's the command that made our high scores work correctly for Snood:

cacls SnoodPrf.40W /E /G "BUILTIN\Users:C"

I've done this once before for another old Windows game, Worms Armageddon (WA). (A great game, BTW. Check "games/wormux" in ports for an open source clone.) With WA, this process was a bit more difficult. First of all, it has a large, multi-directory structure, so it was tough to find the right file. (It was "<WA-top-level>\User\Teams\WG.WGT".) Second of all, the "C"/change access was not sufficient for the regular users to update the file. I don't know why, but in that case I had to grant full access to the file for the scores and saving to work correctly. Keep that in mind, in case you're trying to fix high scores on some other game. Good luck!

Update
I just (re)installed ThinkTanks for the kids. (Another fine game.) But, it also has score/profile saving issues in Windows. To fix, change to the "<TT-top-level>\game\client" directory and update the ACLs (as above) of these four files:

prefs.cs.dso
players.cs.dso
players.cs
prefs.cs

Update 2!
I'm not intending to catalog every Windows game with this issue. But, I've found another one that has put their save files in an unusual place. It is "Luxor 2" by MumboJumbo. It creates a directory, "C:\Documents and Settings\All Users\Application Data\MumboJumbo\luxor2", that all users need to have full access to. And, the files within and sub-directories as well. So, 'cacls luxor2 /t /e /g "BUILTIN\Users:F"' ought to do it.

* I'll have to write about Windows security some time. But, a big part of any reasonable security plan for Windows is ensuring that everyone logs in under their own username and not with administrator rights!

Open Source Census, Notes

Dru Lavigne mentioned an interesting new project in her recent post, "Calling All BSD Users". It's called The Open Source Census. They want to collect data on the use of open source software. I've looked over their site and it certainly has a professional presentation and all of the assurances regarding privacy that you'd want and expect. I have a scan running on one of my home machines right now. It must be pretty thorough -- it takes a few minutes to run!

As Dru points out in her post: "This is an excellent opportunity for the BSD community to show their numbers and to get the BSDs into the operating system piechart in the published reports." And, I couldn't agree more. It's one of the first things I went looking for. (Find it around the middle of this page.) I'm a little concerned that the title of the chart is "Top Linux Distributions". However, the description says that it "reflects data from all Census participants." Still, the numbers don't seem to add up, as the numbers from the chart add up to 442 while the table at the top says that 957 machines have been scanned. Hmmmm. (That mystery aside, I observe that Ubuntu's appalling hegemony continues unabated.)

One more note. I got this error when running it on my 6.3 machine:

stoney$ ./discovery --census-code YOUR-CENSUS-CODE-GOES-HERE
/usr/path/ossdiscovery-2.0.1/lib/plugins/census/census_utils.rb:56: uninitialized constant OpenSSL::Digest::SHA256 (NameError)
from /usr/path/ossdiscovery-2.0.1/lib/plugins/census/init.rb:31:in `require'
from /usr/path/ossdiscovery-2.0.1/lib/plugins/census/init.rb:31
from /usr/path/ossdiscovery-2.0.1/lib/discovery.rb:131:in `require'
from /usr/path/ossdiscovery-2.0.1/lib/discovery.rb:131:in `load_plugins'
from /usr/path/ossdiscovery-2.0.1/lib/discovery.rb:131:in `glob'
from /usr/path/ossdiscovery-2.0.1/lib/discovery.rb:131:in `load_plugins'
from /usr/path/ossdiscovery-2.0.1/lib/discovery.rb:134
stoney$

This one turns out not to be a big mystery. If you check "census_utils.rb" line 56, you'll see a comment on the previous line that explains it's using sha256 and that's not found in openssl 0.9.7, as on FreeBSD 6.3. But, it is found in openssl 0.9.8, as included with FreeBSD 7.0. Ergo, I'm able to run the scan on one machine and not the other. There seems to be a solution to this by running under Java, by way of Jruby (in ports).

If you're interested in playing with this without registering, you might want to go straight here. (It was sort of a pain to find that page before registering.) You probably have ruby installed already and, if so, you can use the smaller download. ... I'm starting to see some advantage in registering before you run the scan, however. It really does take a while. Mine is at 74 minutes and still running and, if I understand things correctly, I'll have to register and rescan with my "census code" if I want to have the report available for my on-line perusal. (Or, I could just submit it anonymously.)

In spite of these minor glitches, I agree with Dru: this looks like it will be a great way to support BSD!