Jump to content

Runtime with limited privileges on Windows


This topic is 6097 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies

Hey, I'm fresh to these forums and to FM. I'm currently working developing a piece of software to replace some legacy software that's built as a FM runtime. I've also been assigned the task of fixing some installation problems with the legacy software.

The situation is that the runtime needs admin privileges to be installed, as normal, but it needs admin privileges to run too, which we don't want. From what I've been able to figure out this is because the runtime or at least it's primary file gets modified because it is the database. Because these are installed in Program Files to be able to modify them you have to have admin privileges. This happens on Mac as well, but I know how to deal with it there.

My planned solution is to set the default installation directory to something other than Program Files. My problem is that I don't know Windows all that well and I don't know where I should choose as the default installation location. Due to the nature of the runtime we're thinking it would be better for it to be a per-user installation instead of somewhere that multiple users can access the same runtime, so the default installation location shouldn't be somewhere like Shared Documents.

My thought had been that maybe a user's AppData would be a decent directory, but I'm not sure.

It seems to me that this must be a more widespread situation so there's either a convention for it or there's some better solution that I haven't been able to find.

Any help would be appreciated and, of course, I am sorry if there was already a topic or some help page about this that I just missed.

Cheers,

Graham

Link to comment
Share on other sites

"Due to the nature of the runtime we're thinking it would be better for it to be a per-user installation instead of somewhere that multiple users can access the same runtime"

Runtimes are only single-user: they cannot be accessed by multiple users simultaneously. Putting a copy of the runtime in each user's folder will mean each user gets an independent copy, and data cannot be shared between users. RThat might be OK if the solution is a personal ToDo list manager, but not if it's a group event scheduler.

If the database needs multi-user access, forget runtimes. Host it with FM Server and get each user to acces it with a copy of FMP client on each computer.

It's probably possible to put the runtime on a shared volume so that multiple people can use it (only one at a time) but that's sub-optimal and will lead to data corruption problems.

Link to comment
Share on other sites

I assumed that he meant that the *file* would require OS-level write privileges if it's in the Program folder, not internal FMP accounts.

Link to comment
Share on other sites

  • 2 weeks later...
  • Newbies

Thanks for your replies. Sorry I didn't get back to them earlier, my spam filter ate them.

Vaughan, you're correct, I was meaning OS-level privileges.

The single/multi user issue is a sticky one. Basically, I think the program doesn't really suit a database model, which is why we're writing a new version. It's most similar to a normal program, any user should be able to use it and they each have their own preferences etc., but since there can only be one back-end for the runtime everyone would be sharing the same prefs. Therefore, we decided to go with one copy per user.

Anyway, unless there is a better location for it than the AppData directory we'll just go with that.

Thanks for the help,

Graham

Link to comment
Share on other sites

This topic is 6097 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.