Doesn't work under multiple logins on the same computer

[jch]

My kids each have their own login on our MacBook (for time control etc).

Trying to install BCS so that they can each run it under their own account.

When I install it under one account, it'll then run properly in *only* that account.  Anyone else who tries to launch it will just see a blank (white) window.

Even if I change the permissions on the installation folder to Everyone RWX, it won't work.

How do I fix this???
.../j

[ArchieDeBascule]

Hello Chronic Logic developers! I bought Bridge Construction Set in the recent MacZOT thingy. It's good clean fun, but I have a few criticisms, the first of which is relevant to JCH's post. I'm probably going to come off as arrogant for posting this much, even though I'm trying to be helpful! But anyway...

I notice that BCS stores the user's settings and bridge files inside its .app bundle. This is a rather bad idea. In my opinion the simplest adequate solution would be to change BCS to store these things in the user's Library folder under, for example, ~/Library/Application Support/Bridge Construction Set.

If you wanted to be a bit more flexible you could perhaps allow the user to customise the path BCS writes files to. That would naturally require you to store the path in a known location, such as a settings file like ~/Library/Preferences/com.chroniclogic.bcs.txt (Apple recommends using reverse domain names like com.chroniclogic to avoid name-space clashes with any other programs called BCS).

You could even use proper open and save dialogues--but I don't want to bore people with the obvious. The point of this post is that applications should not put settings files in the application bundle because it causes several problems, including the following:

Usability - From an everyday user's perspective, a bundle is just a file; one that they double-click to start a program. They shouldn't need to know that there's a special way to open it that lets them mess with the executable files and resources inside, as with http://www.pontifex2.com/smf/index.php/topic,1106.0.html

Multiple users - By storing the user's personal files inside Bridge Construction Set.app (or any folder like the main /Applications folder that isn't personal) you compel each user to keep their own copy of it their personal ~/Applications folder. This makes it easy to accidentally skip over a copy of it when updating to the latest version.

Privacy & security - The alternative to keeping multiple copies of BCS is to keep one copy and set its permissions so that everybody can read and write the relevant files. This causes much bigger problems than it solves: Now anyone can mess up the program for everyone else, even accidentally! (That's what personal logins are supposed to avoid.) I don't recommend opening up the permissions of BCS even if you know which files to do it to.

Installing updates - This is supposed to be easy: The user drags the new version of BCS to where the old one is, then they agree that they want to replace the old one -- except that they've just erased all their progress in BCS! BCS is the only program I've used that has quite such a dramatic design flaw. Because of it, you have to instruct your users in tediously and carefully replacing all copies of the program, as with Gish: http://www.pontifex2.com/smf/index.php/topic,989.0.html (I hope they keep backups!)

Signed code - Mac OS X uses cryptographic signatures to ensure that each program is the program it claims to be when it tries to access something security-sensitive such as the Internet or the Keychain. BCS accesses neither, so this is not currently a problem. But it's worth considering that BCS's self-modifying antics could make it appear to be a different program each time it runs, thus defeating the point of signed code.

I do not know the specifics of signed code but I thought this potential issue was worth mentioning just in case. Anyway, please fix the underlying issue and signed code probably won't be a problem. The underlying issue, as you know, is the separation of executable and personal data. I urge the Chronic Logic developers to improve their software as such. Thank you!

[Chronic Logic - Josiah]

Good points, we have done this with the Linux version using the users home directory and it would not be hard to make it work like this in OSX as well.  Using open and save dialog boxes would require programming OSX specific code which is exactly what we try to avoid (to keep the game easy to build for all three operating systems).  I will try and take a look at changing where files are saved in OSX for the next patch.

[ArchieDeBascule]

Thank you; I look forward to future versions!

[ArchieDeBascule]

Hello again! I've just updated my Bridge Construction Set to the latest version on my Mac. It's nice to have lots of new bridges to play with, but I'm not sure if I'd have been able to install the update without first having studied computer science for a couple of years.

The usual Mac method of replacing the old version's application bundle, bcs.app, with the new version by drag-and-drop is not suitable for Bridge Construction Set. Unfortunately, anyone who simply replaces the old version like that will wipe out all their progress, all their bridges, their licensing info, etc, because BCS stores all that stuff inside the application bundle, which, I thought we'd agreed, was a really really stupid place to put it.

It's a good thing I knew about this massive design flaw in advance and was able to diff the old and new bundles using Terminal.app and copy the necessary files to the new bundle. But how many of your customers do you think even know what a Mac application bundle is, let alone how to transplant certain parts of one bundle into another?

Would you please store user data in a sensible place, please? You could put it in a hidden folder in the home directory, which might work just by copying the code from the Linux version, or you could make BCS more Mac-like by storing the user data in "~/Library/Application Support/Bridge Construction Set". Either of those options is about a zillion times better than storing that sort of thing in a place that gets deleted with every update.

[Chronic Logic - Josiah]

I will try and take a look at changing where files are saved in OSX for the next patch.

[Chronic Logic - Josiah]

I have this fixed and working, I will release it with the next patch in the next week or two.

[ArchieDeBascule]

Nice!

[Chronic Logic - Josiah]

The latest version of BCS (1.39) is available.  It stored bridges and settings in the ~/Library/Application Support/ folder on OSX.

[ArchieDeBascule]

This is good stuff! You've solved my pet peeve with BCS and you've nearly solved JCH's (above) problem too. It looks like the last thing preventing multiple users (on the same Mac) from using (one copy of) BCS is that some of the file permissions are a bit too restrictive.

If BCS is to work properly in the /Applications folder like all good programs, its files need to be readable (and in some cases executable) by all, but some of them aren't. While you're changing file permissions, may I also suggest not setting the execute bits unnecessarily as I'm told that can sometimes be a security problem.

While all of BCS's folders and symlinks need their execute bits set (I think that's permissions mode 755), only a few other files need 755 and the rest should have permissions mode 644. Since you (Josiah and friends) know your software much better than me, please correct me if I'm wrong but I'm of the opinion that:

In the Bridge Construction Set folder, every file should have permissions mode 644, except:
all folders
all symlinks
Bridge Construction Set/bcs.app/Contents/Frameworks/OpenAL.framework/Versions/A/OpenAL
Bridge Construction Set/bcs.app/Contents/Frameworks/SDL.framework/Versions/A/SDL
Bridge Construction Set/bcs.app/Contents/MacOS/bcs
Bridge Construction Set/hwconfig.app/Contents/Frameworks/SDL.framework/Versions/A/SDL
Bridge Construction Set/hwconfig.app/Contents/MacOS/hwconfig
...which need 755.

I also wish to point out that BCS version 1.39 still says version 1.37 in its Get Info window in the Finder (whoops) and that I believe other Chronic Logic Mac software, like Gish, could be improved significantly by applying the above principles.

Specifically, while I haven't looked inside Gish's application bundle because I don't own a license, I hear that upgrading Gish for Mac is about as fiddly as upgrading BCS for Mac used to be. But now that BCS has been (mostly) fixed you can tell your Mac customers that they need to go through the upgrade rigmarole just one more time, and then their bridges will be in their Application Support folder, safe from accidental deletion.

[Chronic Logic - Josiah]

Thanks for the information.  I did not change any of the permissions from whatever they defaulted as.  Is it normal to have to do this when deploying software for OSX?  I will look into it and try and make these changes when I update Gish with the same changes.

[ArchieDeBascule]

Most users don't really understand file permissions, so for their sake the permissions should already be set for normal use before the user drags the application from the disk image. Even users like me who have a reasonable grasp of file permissions don't want to set them for each update of each application we install. If you could arrange it so that each application you send out has its permissions set ready for normal use, that would be really nice.

To clarify, I believe "normal use" includes these scenarios:

a) A user with admin privileges drags the application from a disk image to the main /Applications folder and expects everyone on that computer to be able to use the new application. (With BCS, each user would have to type in a licensing code the first time they used BCS — even if the license is per-machine rather than per-user — but I tend to think that's a reasonable one-off inconvenience.)

b) A user wants to install the application for their use only (or maybe they can't write to the main /Applications folder) so they make the folder ~/Applications and drag it to there.

c) A user made up their own filing system and installed the application somewhere else and they expect it to work. I personally put software that I consider to be a "utility" in /Applications/Utilities even if the developer says to "put it in /Applications" and I put games in /Applications/Games (a folder I made) so that they don't distract me from my other tasks (well, not as much...)

There is nothing about Mac OS X that should stop the vast majority of Mac applications from working in these scenarios. I believe that BCS is already ready for scenario b (indeed, when previous versions stored personal data inside the application bundle, scenario b was the only one that worked) but needs slightly more permissive permissions (globally readable and, where appropriate, globally executable) in order to fully work in scenarios a and c.

I hasten to add: please don't go the super-easy route and make every file in BCS.app globally writeable or executable as that would open up a security hole on the user's computer. By the way, thanks for applying these principles to your other products. I love the idea that I can help make Mac software better even though I haven't yet learnt to program with Cocoa!

[Chronic Logic - Josiah]

I have a new build with file permissions set.  If you could test it that would be great.  I will message you with a link.

[Chronic Logic - Josiah]

Looking into the file permissions more I see a bunch of strange permissions.  I am not sure how the file permissions even got set  like that but I have fixed them all and will be update the demo and full version soon.

[ArchieDeBascule]

That's a relief! I've been wondering what would be the best way to list all those weird permissions...