I don't know multi-users support in the way of identifiers are planned, but there are a few I could use for my script, as posted in the other forum.

$osuser - login name of operating system user, with properties of

.homedir
.appdir
.description
.group -
.privledge
.mircaccess - this is if user can read as well as write to mIRC home dir

$userdatadir - directory where user specific mIRC application data is.

$permsn - the read/write permissions of a file

The idea is, to have the script as administrator, as read only, and all the keys and settings files will be private and user

I'd also like to see the following command:

/chnpermsn - changes permissions of a file

Most of this can be done with $com... You could also use hash tables for settings (I use hash tables like a personal registry). The hash table saved files would be named for the current user logged in. Load the proper setting file on startup.

The hash tables also need to be saved anytime a change is made. To make this simple, instead of saving with each change, have a hash table entry to indicate that a change has been made, but not saved. Then check for this hash table entry with a timer that execute about every 5 seconds, save the table if it's found and delete the hash table entry.

A backup system is helpful too. When saving, rename the old file. When loading, if the regular setting file is missing, copy the backup to the regular name of the file, then load it.

Then just setup folder permissions properly.

Although it sounds good to use hash tables for all of your settings, keep in mind that many large hash tables will use resources and saving them can "freeze" mIRC for a noticeably period of time if the table(s) are large. Hash tables are great and they are fast. However, that doesn't mean they are the best method every time. For settings that aren't used frequently, a settings file, or even variables, is more appropriate.

This is a major issue with Invision because it has different settings for each network a user is on and just being on 3 networks can generate around 200 hash tables of settings. They aren't huge tables, but there are many of them and saving the settings can "freeze" you for 5-10 seconds. Most of those settings aren't even used most of the time, so there's no reason to have them in a hash table to begin with. This will eventually be changed whenever I get around to it (it's a big job), but for now it can be troublesome.

Anyhow, that example shows one reason why it's best to not use hash tables indiscriminantly. Use them when it makes sense rather than all of the time. If you don't check the settings frequently, then the occasional $read/$readini isn't going to be a problem considering you're freeing up resources throughout the entire time that you are running the script by not using the hash table.

That's just my opinion (I *do* love hash tables, btw), but you can choose whichever method you prefer.

I use such a system and do not have these problems... Perhaps your are trying to save everytime something is changed in the hash table, which isn't a good idea.

The use of variables should still be used for things that are constantly being modified. Since "settings" usually only read, and not change often, hash tables are a very fast and organized method for the handling of this information.

The point is that they aren't usually read very often either (if at all on a given session). If they are rarely used, there's no need for them to use resources just to sit in memory.

what does this have to do with hash tables??/


also, explain to me how exactly to get operating system user information from $com, I need to get the current user. I am looking for events to make this easier to make scripts run load user specific data files stored in their home dirs.

Also, I am pretty sure as is it'd be possible to read/write permissions/attributes with bread/bwrite, but thats a going to be a little tricky to say the least.

Why do mIRC still save settings to its own directory? That's so Windows 95

Best solution for multi-user support is to save all settings to "%USERPROFILE%\Application Data\mIRC" instead.

The installation could suggest moving setting files to that directory for those who are upgrading.

It has already been stated that the next version will allow saving settings to appdata.

By the way, when mIRC loads it throws your mIRC.ini into.. yep, you got it-- the memory.. so having a hash table to store settings wont really be that big a change.

Besides, your settings wouldnt take up more than a few kilobytes, that really isn't a lot.