On Aug 18, 2006, at 9:47 AM, John McKernon wrote:
The problem with this method is that unless you're logged on as an
Administrator account, you may not have permission to write
anything to the local hard drive's program files folder.
Installers often ask for an administrator's account and password,
thereby permitting the user to put things where they would
otherwise be blocked.
This issue is most common on Windows, but it can also come up with
Mac OSX, too. I discovered it the hard way some years ago when a
customer of mine at UC Berkeley found that he couldn't install my
software and had to wait a month until an IT person could get there
to do it...:(
MACINTOSH OS X:
In OS X, there is a Home->Application folder (which is hardly ever
used) which any user can drag or install an application. This does
not require Admin privs since the application can only be accessed by
that user. I do not believe that all installers are capable of
supporting this feature (Adobe software comes to mind), but it is a
option for most Macintosh software.
Also, in regards to writing files... there is no problem if the app
is only writing to the user's space. For example, one of my apps
automatically creates a REALSQLdatabase in the Home->Library-
>Preferences folder for storing all of the data for the user upon
first launch. This data is not intended to be access from other user
accounts and therefore has not had any issues with permissions
(although if the user does something stupid, permissions could get
screwed up in their own home folder).
If the files you need to install are libraries or resources (like
pictures), you can use the Mach-O application format and just store
the items in the application package. Then there is no need for hard-
coded links to files, you just follow the relative path from
App.ExecutableFile.
In terms of Permissions and Documents, they should be written to the
user space anyways. Only a few rare files would need to be written
in the global space, and it is easy to check if the active user has
permission to write in certain global space or not (simple
FolderItem.IsWriteable test). If not, then you could just write the
necessary files to the local user space... and upon each launch test
for the files in both locations... writing only when both sets of
files cannot be found.
WINDOWS:
Regarding post-install file writes, the same is true for Windows if
you limit all of your read/writes to the local User space. But
perhaps it is easier for Windows installs to just let the installer
write the files you need.
Regarding IT Staff, well we all like to feel needed. =)
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
