Storing information in the Registry

[Eric]

I'm working on a multi-threaded bot with user profiling with password support, that stores the configuration of the bot in the system registry instead of a text file.
I've gotten past the user profiles and user profile passwords part, but I'm stuck on the storing the information for each individual bot for the user profile.  

Since you can't seem to store two keys of the same name, I was thinking of doing something like this to store the information of each bot: {MD5 Hash of the bot username-FILETIME of when that specific bot username was created}, so basically each bot would look something like this in the registry: {62415412-332412212}.

Does this seem like a decent way of storing information? Or are there any other better possibilities?

[Skywing]

I allow the user to specify a unique name for the profile.  All commands that refer to a specific profile use the profile name.  This lets people pick meaningful unique names, e.g. "Skywing USEast" or "Skywing USWest".

[Eric]

I allow the user to specify a unique name for the profile.  All commands that refer to a specific profile use the profile name.  This lets people pick meaningful unique names, e.g. "Skywing USEast" or "Skywing USWest".

I was actually referring to the bots that would fall under the profile (which would be user selected).

[Skywing]

I have a profile == a bot.  Not sure what you're trying to do.

I store stuff like this:

Have a registry key somewhere\Profiles.
Each profile should be placed under somewhere\Profiles under a key named according to the profile.  To keep with the example I gave, the key somewhere\Profiles\Skywing USWest contains configuration data for that instance.

[Eric]

Basically it would be like something like:

HKEY_LOCAL_USER\Damnation
HKEY_LOCAL_USER\Damnation\Profile
HKEY_LOCAL_USER\Damnation\Profile\Username
HKEY_LOCAL_USER\Damnation\Profile\Username2
HKEY_LOCAL_USER\Damnation\Profile\Username3
ect.

The information stored within the Username sections would be the information for each bot, the profile would contain the bots to load, but the way shown above wouldn't work if the user wanted to load two of the same usernames in a single profile.

[Skywing]

Basically it would be like something like:

HKEY_LOCAL_USER\Damnation
HKEY_LOCAL_USER\Damnation\Profile
HKEY_LOCAL_USER\Damnation\Profile\Username
HKEY_LOCAL_USER\Damnation\Profile\Username2
HKEY_LOCAL_USER\Damnation\Profile\Username3
ect.

The information stored within the Username sections would be the information for each bot, the profile would contain the bots to load, but the way shown above wouldn't work if the user wanted to load two of the same usernames in a single profile.

Yes..  I use a user-defined "profile name" instead of the Battle.net username to uniquely identify instances.

Any corresponance between "Skywing USWest" and the Battle.net username/Battle.net server the instance logs on with is purely up to the user.

[Eric]

To be more clear: Within each profile, there will be multiple users (Battle.net account usernames)

A better example:
HKEY_CURRENT_USER\Damnation
HKEY_CURRENT_USER\Damnation\Profiles
HKEY_CURRENT_USER\Damnation\Profiles\Eric
HKEY_CURRENT_USER\Damnation\Profiles\Eric\LoRd[nK]
HKEY_CURRENT_USER\Damnation\Profiles\Eric\WaRLoRd
HKEY_CURRENT_USER\Damnation\Profiles\Eric\Ze][2o
ect.

[UserLoser.]

Just sticking my nose in here:
I do what Skywing does, I don't store it by Battle.net account either..

Example:
HKEY_LOCAL_MACHINE\SOFTWARE\UserLoser\UserBot\Profiles\Main

Main is my client's profile to load by default, unless the user specified a different profile to automatically load when the program starts.  Inside Main, is all the configuration, I also store a <profile name>-Backup just incase anything happens

Another handy thing:

HKEY_LOCAL_MACHINE\SOFTWARE\UserLoser\UserBot\Other Settings

In there I have:
GUI
Statstrings
Version bytes

GUI would be FlashWindow when recieving a whisper, Font name, Font size, other various fun things..
Statstrings holds the statstrings you can specify for older products..
Version bytes stores version bytes obviously, much easier to do this instead of compiling a new executable each time there's a new version byte... Although BNLS is an option

[Kp]

It seems to be it might be easier to just have a restriction of one username per profile, and let the user clone profiles as they add more usernames they wish to use.  If the client is intelligent about profile copying (and maybe even profile templates or cascading profiles if you want to get very fancy), it'd be very easy for the user to configure even then.

Also, I recommend storing under HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE, as you can't guarantee the user will have write permission to HKLM.  One of my common solutions to this is to open it under HKLM during bootup, but open HKCU if I can't get read/write access to HKLM.  It seems to work pretty well, though there may be more elegant solutions out there.

[UserLoser.]

It seems to be it might be easier to just have a restriction of one username per profile, and let the user clone profiles as they add more usernames they wish to use.  If the client is intelligent about profile copying (and maybe even profile templates or cascading profiles if you want to get very fancy), it'd be very easy for the user to configure even then.

Also, I recommend storing under HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE, as you can't guarantee the user will have write permission to HKLM.  One of my common solutions to this is to open it under HKLM during bootup, but open HKCU if I can't get read/write access to HKLM.  It seems to work pretty well, though there may be more elegant solutions out there.

Thanks -- I never knew that, I'm on XP Home and I have pretty much no restrictions at all

[iago]

It seems to be it might be easier to just have a restriction of one username per profile, and let the user clone profiles as they add more usernames they wish to use.  If the client is intelligent about profile copying (and maybe even profile templates or cascading profiles if you want to get very fancy), it'd be very easy for the user to configure even then.

Also, I recommend storing under HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE, as you can't guarantee the user will have write permission to HKLM.  One of my common solutions to this is to open it under HKLM during bootup, but open HKCU if I can't get read/write access to HKLM.  It seems to work pretty well, though there may be more elegant solutions out there.

Thanks -- I never knew that, I'm on XP Home and I have pretty much no restrictions at all

If you're admin you probably don't

[Kp]

Thanks -- I never knew that, I'm on XP Home and I have pretty much no restrictions at all

If you're admin you probably don't

Right.  However, it is generally considered unwise to run potentially exploitable applications with more privileges than necessary.  A corollary to this is that you should consider all applications potentially exploitable.  Therefore, I tend to encourage people to use non-administrative accounts whenever possible, so that if a program gets away from them (whether it be viral, a rogue DLL, or just badly written user code), the damage that it can inflict will hopefully not be sufficient to kill the entire system.  You can use RunAs to launch those few necessary applications as an Administrator without having to log out.