Where should runtime solutions be installed?

[TheTominator]

I am preparing my Developer 5.5 runtime for Windows, Mac OSX, and Classic Mac OS.

I thought I was ready to deploy using installer programs under both Windows

(Windows Installer .msi file) and Mac OS X (Package Maker .pkg file) but I am

not clear WHERE to install the runtime files.

Is there any standard solution of where to have the installers put the

runtime solutions?

The problem is that my solution might be used by anybody with an account

on the computer. It is a single-installation license, not single-user.

So it makes sense to install it in the Program Files/Applications area.

But I am concerned that non-administrator users won't have the

necessary permissions to use the program if the actual database files

are stored in admin-only areas.

Under Mac OS X, the PackageInstaller won't let me configure it to

install into the user's Home directory nor into the /Users/Share

directory.

I also have an Exports directory in the same directory as the solution

to facilitate scripted export/import so the write-access problem goes

beyond the initial set of bound database files.

Another problem may be that (at least under OS X) you can have multiple

users logged in at the same time. What happens if multiple users try to

use the runtime at the same time?

-Tom

[TheTominator]

I did some testing using Windows 2000 and discovered that the entire

runtime solution works when installed in the "Program Files" directory.

Apparently the runtime environment has write write-access there even

for normal-level users. That suprises me. I guess I was making unwarranted

assumptions about the access restrictions based upon my UNIX experience.

Windows 2000 does require Administrator level access to run the installer but

I am free to add/delete/modify the files in the "Program Files" directory

by hand from a normal user account.

Can anyone comment on what might be different about Windows OSes

later than 2000? Have they changed the security model?

[Reed]

Well I don't know much about installer programs, but I know that you'll have problems if multiple people try to access the same runtime in a fast-user-switching setup. The first runtime puts a lock on the file, and the second instance generates an unhelpful error dialog and asks you to find a file....

Can you make an installer that puts a copy of the entire runtime in each user's ~/Documents folder, and puts an alias to the runtime on the desktop, start menu, dock, etc? That way each user will have his own data files and there won't be any conflicts.

[TheTominator]

Well I don't know much about installer programs, but I know that you'll have problems if multiple people try to access the same runtime in a fast-user-switching setup. The first runtime puts a lock on the file, and the second instance generates an unhelpful error dialog and asks you to find a file....

Good to know. I will be testing the normal Mac OS X user setup today including the multiple,

simultaneous user scenario.

What happens in a similar situation under Windows? Is there a similar feature that

allows two or more simultaneous Windows users at the same machine? I'm not

worried about additional users through remote logins since advanced users like

that can take care of themselves.

Can you make an installer that puts a copy of the entire runtime in each user's ~/Documents folder, and puts an alias to the runtime on the desktop, start menu, dock, etc? That way each user will have his own data files and there won't be any conflicts.

I could with some programming, but the free installer creating packages I am using can't.

Maybe the Windows one can. I haven't tried out that scenario. It does have the option

to add entries to the Windows Start menu and a shortcut onto the desktop.

I am using that option to put the runtime executable into the Start menu.

I expect third-party, commercial software can create this type of installation for

Mac OS X. Maybe the PackageMaker program can too, but I haven't found this

flexibility yet. In particular it prohibits installation into the /Users path.

[TheTominator]

Can you make an installer that puts a copy of the entire runtime in each user's ~/Documents folder, and puts an alias to the runtime on the desktop, start menu, dock, etc? That way each user will have his own data files and there won't be any conflicts.

Actually, the hard part about what you wrote is "in each user's". I don't think you will

find an installer that will put a copy into each user's simultaneously. The most that

you will find is for the installer to put one copy into that particular user's directory, e.g.

the user who is running the installer. It probably wouldn't be wise to do it for every

user since that would violate lots of conventions and would be hard to maintain in

the long term. What happens when a new user is added later? How do you deal with

upgrades to the solution?

Thus I would recommend informing your users to each run the installer before

using the program to install it into their own area.

For PackageMaker under OS X, I have found an option for the user to specify the

install directory and override the default. I plan to allow this in my distribution to

allow the users to install it into their home directory. This will permit non-admin

users to install it conveniently. That works out very well since the Home directory

is only one click away in the installation dialog.

[TheTominator]

I have just tested out using a non-admin account under OS X.

As expected, the runtime solution does not work if the entire folder

is installed in Applications. The non-admin user does not have

write access to that directory and FileMaker opens the database

files as read-only.

So I guess my only options are to install to /Users/Share to give

access to multiple users (one at a time), or ~/Documents to

give access to only one user.

I was surprised (and a bit shocked) that Windows 2000 permitted

the runtime to work when installed in the Program Files heirarchy.

It appears that non-admin users have essentially full access to

the filesystem. Is this true of Windows XP as well?

I don't currently have XP to test it out on.

[TheTominator]

I have just tested out using a non-admin account under OS X.

As expected, the runtime solution does not work if the entire folder

is installed in Applications. The non-admin user does not have

write access to that directory and FileMaker opens the database

files as read-only.

So I guess my only options are to install to /Users/Share to give

access to multiple users (one at a time), or ~/Documents to

give access to only one user.

I found the solution for MacOS X.

The permissions on the database files themselves need to be changed

to read/write for group and other if the database is to be fully used by

any user besides the one who installed it. This is needed even if the files

are stored in /Users/Shared. I have not yet been able to get the Package file

to do this automatically on install. I am hopeful that I can do it as part

of the post-processing after the install.

[TheTominator]

Alright. Things are good. In fact, I'm amazed.

The MacOS X PackageMaker and the .pkg file format is much more powerful

than I had first guessed. I now know that it is very doable to install the

FileMaker runtime solution into the Applications folder on a Mac OS X

system and have all users be able to use it fully albeit one at a time.

With the standard Mac OS X Package file format you can have the options

to run scripts (programs) before and after the install and before and after

an upgrade. The secret is that the Package file isn't a file at all. It is a

folder. Open up the folder and put your specially named document or

program files inside (ReadMe.txt, License.txt, preinstall, postinstall, preupgrade,

postupgrade, and so on). I put in a Bash script to change the file and folder

permissions at the end of the install to allow all users

to have read/write access to the database files in the solutions folder

inside the Applications folder. Worked like a charm.

In addition, the Installer lets you present a ReadMe file and a click-through

License file to require the user to agree to your license before installing.

It is way cool and professional looking as well as professional performing.

[Reed]

So is the OS X packagemaker part of the Developer Tools? In windows, how do you make an msi installer? Do you need visual studio or is there a free product to do this?

Up until now, I've always just distributed runtimes as .zip archives with a README telling users to copy the folder to their ~/Documents folder and to make aliases in the appropriate places. I've never made up a license agreement either, but then I've never tried to sell anything either....

[TheTominator]

So is the OS X packagemaker part of the Developer Tools?

Yes. I am using Panther. You may need to install the Developer Tools off of the

Panther CD or, if you had Panther pre-installed with a new machine, the Developer Tools

may be a large Developer.mpkg file on your hard drive inside Applications/Installers/Xcode Tools.

With Developer Tools installed, the PackageMaker application is found in

/Developer/Applications/Utilities.

In windows, how do you make an msi installer? Do you need visual studio or is there a free product to do this?

I am not aware of a Microsoft-provided free program to make .msi files. I would be pleased

to hear of one. I have no experience with Visual Studio. I am primarily a Mac, Unix, web,

and FileMaker programmer.

I use Advanced Installer (www.advancedinstaller.com) to create the .msi files.

It is free for simple installations such as the FileMaker runtime solutions. It has more

advanced features that are unlocked in the paid version. Advanced Installer was the

first program that I encountered that satisfied all of my criteria of being of sufficient

quality for the task and free for this commercial purpose (some others are free only

for personal or non-profit use). I am interested in hearing about other similar

solutions to make .msi files or alternate Windows installation methods.

Up until now, I've always just distributed runtimes as .zip archives with a README telling users to copy the folder to their ~/Documents folder and to make aliases in the appropriate places.

I was going to just distribute archives of the runtime folder but my target audience

has a wide range of computer skills and I am under the impression that most

Windows users expect some sort of installer program to take care of everything.

Once a program is magically put onto the computer, if it doesn't have a menu

selection in the Start menu, too many Windows users will get lost. For some of

my target users, this might be the only program they use (their killer app) aside

from e-mail and the web.

Personally, when installing software for myself, I much prefer to control what gets

installed where. But for this commercial endeavor, I need to meet my customer's

expectations of what software should look like and behave like.

For my free distributions, I can afford to train them to be a bit more

"in control" over their files, menus, and shortcuts.

[TheTominator]

I did some testing using Windows 2000 and discovered that the entire

runtime solution works when installed in the "Program Files" directory.

Apparently the runtime environment has write write-access there even

for normal-level users.

One caveat to this discovery. This was done with Windows 2000 using a FAT32

filesystem. There may be a tighter security model under NTFS. I have no

experience yet with Windows XP but I have some clues that NTFS may be

the default filesystem for XP. Unless someone can provide advice on this,

I may have to reformat under NTFS and reinstall Windows 2000 and all

my programs to test out the behavior there.

Can someone save me this trouble?

[TheTominator]

My initial concerns in the post that started this thread turned out

to be well founded.

I reformatted my Windows 2000 installation and used NTFS.

I created a restricted user account (not "Standard/Power User") and found

that the default filesystem permissions prohibit the runtime solution

from working when installed into Program Files. The database

files are opened as read-only and therefore are not fully usable.

Conversely, "standard" user accounts are afforded read/write access

to the Program Files directory. The runtime solution installed there

works fully for them.

Since I want any user to be able to use my solution, I will have to

work out the permissions issue. This effectively means that my

previous success under Windows was a red herring since

it was just my use of over priviledged user accounts that accounted

for my success.

It could be that the vast majority of my users are using powerful

user accounts as their normal day-to-day ones and my worries are

therefore mostly academic, but I don't want to discourage any Windows

user from using the right type of user account commensurate to their

security needs. Therefore I will have to find the proper installation

location and proper set of permissions to meet all users.

I am still looking for a complete answer to what is appropriate for

Windows XP Home and Pro. Is the security model no different from

Windows 2000 Professional?

I tried to find the answers myself before posting to this forum.

Are there any documents already online that address this issue?

[bcooney]

I realize that this is thread is a bit old, but it discusses issues that I feel are still relevent: where to install the runtime and what permission issues are there to handle.

Any info to share?