Big-O Software

This question applies to AIM+ at the seconds, but it really goes for a lot of programs as well.


Th thing is ive recently been using my computer which has now been set up for family use.

Im not used to the multiple user accounts that XP offers.

So the question is how would i go about being able to use AIM+ on two accounts? When i try to run it from the account i installed on, its fine, but if i try from another account, it says registry error.

Do ya gotta install for every user account or something?



how's this whole multiple user crap work?

I've seen it work before.. not sure how they got it to set up though..
I believe you have to do the initial install as the Admin so it sets up for all users.

Then you can just clone AIM for each one of the accounts, and have it Auto-start when Windows loads up.

I believe Wasted is right. If you do your software installations as the Administrator user, then they are setup to be available to All Users (For example, if you go to Documents and Settings, you'll notice a folder called 'All Users').

Some installation scripts ask you if a program is to be available to all users or just the user doing the installation, but I don't think the AIM+ program does that.

If you install on the Admin account it will NOT install the registry entries for every account.

That is the way we install programs that are available to all users at work. You log in as the Administrator and then install, otherwise, it won't run. I was under the impression it made the registry entries under the LOCAL_MACHINE as opposed to CURRENT_USER.

When you're logged in as an administrator, programs have access to HKEY_USERS, which contains the settings for all users, arranged by SID. The SID is a number used to identify a user.

Method 1) Go into "HKEY_USERS\[YOUR SID]\Software" and export the Big-O stuff into a .reg file. Open the reg file in notepad and do a global search and replace for the SID, replacing it with another user's SID. Save the file, then merge it with the registry (just execute the file). The next time that user logs in to Windows they will have your settings for AIM+. You can do this with the whole Software key if you want.


Method 2) *Easier* Go to "HKEY_CURRENT_USER\Software" and export the Big-O key contained in there to a place where all users have access. Log off. Log in as each of the other users and merge the file with the registry. Any user (including Guest) should be able to do this because it only deals with the current user settings. Guest's settings aren't saved after logging off though.

harra wrote:That is the way we install programs that are available to all users at work. You log in as the Administrator and then install, otherwise, it won't run. I was under the impression it made the registry entries under the LOCAL_MACHINE as opposed to CURRENT_USER.

Actually I was under that same impression until recently. I think some programs do local_machine and others don't for whatever reason.

hmmm....

So you are saying that if you login as Administrator and do the installation, it puts the registry entries under the Administrator in the registry. Interesting, but not illogical.

I guess it comes back to the observation I made where some installation scripts ask you if the program is to be used by the current user or all users. Other developers may take the "better safe than sorry" approach and just stick it in the LOCAL_MACHINE bucket. Once there, it should be available to all regardless of the user.

I do see why you might not put it in the local_machine place... If you don't want users using a program that you want to use it would be logical not to have it there.

In retrospect it can be annoying though not to have it there.

harra wrote:hmmm....

So you are saying that if you login as Administrator and do the installation, it puts the registry entries under the Administrator in the registry. Interesting, but not illogical.

I guess it comes back to the observation I made where some installation scripts ask you if the program is to be used by the current user or all users. Other developers may take the "better safe than sorry" approach and just stick it in the LOCAL_MACHINE bucket. Once there, it should be available to all regardless of the user.

It depends on who wrote the program. If you're not logged in as a member of the administrators group, then installers won't have access to HKEY_LOCAL_MACHINE or HKEY_USERS. They should have access to HKEY_CURRENT_CONFIG, HKEY_CURRENT_USER, and HKEY_CLASSES_ROOT. This prevents one stupid user from screwing up the computer for everyone. A well-written installer will notice if you're logged in as an administrator and either put configuration settings in the registry for everyone using HKEY_USERS, or put a flag in the registry under HKEY_LOCAL_MACHINE that tells it to initialize configuration when it's run by another user.

This is really a stupid way to do things though. Jasc Paint Shop Pro does it the right way. When you run the EXE, it checks to see if it's been added to the registry. If it hasn't, then it adds the appropriate keys.

Unfortunately, all of my installers to date have been unaware of multi-user setups. The easiest solution for most people is to install the software once for each user that needs to use it.

If any developers have good links/articles about designing software for multi-user windows setups, I would really appreciate them. I have been trouble finding good information about this stuff (including the registry stuff that Master Jedi was mentioning).

I believe the standard .msi setups have an option for that (they are the standard windows installers in the 2k/xp setups i believe.)

Big-O Ryan wrote:Unfortunately, all of my installers to date have been unaware of multi-user setups. The easiest solution for most people is to install the software once for each user that needs to use it.

If any developers have good links/articles about designing software for multi-user windows setups, I would really appreciate them. I have been trouble finding good information about this stuff (including the registry stuff that Master Jedi was mentioning).

The easy answer is simply don't store your preferences in the registry.

For a program like AIM+, you could have one settings file for each windows login...not necessarily an INI file. For instance since there are exactly 16 settings that are either 1 or 0 in the registry, you could use 2 8-bit numbers (or a 16-bit number) to represent them. These 2 numbers could be the first 2 bytes of the settings file. Then you'd add the rest of the settings to the file afterwards, putting the fixed-length ones first (and adding comments in your code to remind you what setting is stored in what bit/byte). After those would come the variable length stuff like the path to AIM and the logging directory. Have a variable store the starting locations (where they start in the file--that sounded kind of ambiguous) of these settings (16-bits will probably be long enough since your settings file will probably never be more than 65K). These numbers should go in a place where you can read them from the file easily. The beginning or end should do. Now it should be easy to read/write settings to the file (even easier than an INI file and it will be smaller). If a user tries to run AIM+ and they don't have a settings file, then it would just create one with default settings. I know this takes more code to implement than the registry settings, but ultimately it should work better.

As for installers, I typically write my own. To store files in an EXE, you can just append their contents to the end of the EXE and then the code in the exe can read what's been appended to it in much the same way as the settings file I described. The settings file should alleviate the problem of finding a really good packaging product.