Zugg Software :: View topic

Posted: Tue Jul 25, 2006 7:31 pm

This is from the thread talking about Windows Vista.

I'd like to have a discussion on the correct place to store user settings for CMUD. I'd like to come up with something that works well on both Windows XP and Vista.

In the past, I have stored everything within the CMUD directory itself. This causes problems when CMUD is installed into the Program Files directory, since normal user accounts do not have write permission to this directory. So you get an error when trying to create a new package or when storing your CMUD.INI preferences.

I don't want to have too many different locations that contain CMUD files. But I think I can handle having two locations: one for the CMUD program files (like in Program Files), and another place to store user-specific settings.

One option is creating a CMUD subdirectory in the "Documents and Settings\Username\Application Data" or "Documents and Settings\Username\Local Settings\Application Data"

However, I have a *BIG* problem with this option. For some insane reason, Microsoft has chosen to make both the Local Settings and the Application Data folders Hidden!! I know this might come as a big surprise, but I have run into a lot of users who don't understand Hidden files and how to show them. So putting CMUD settings here would make them really hard to find for some users who want to move their settings to another computer or to back up their settings.

The second option is to create a CMUD subfolder in the My Documents directory. Perhaps something called "My MUDs" or "My Sessions" would make sense. I like this option a bit more since it's easy to find stuff within My Documents and it's fairly painless to move My Documents to other disk locations (unlike the Documents and Settings folder).

What do people think?

Posted: Tue Jul 25, 2006 7:49 pm

I like the directory under My Documents. I'm biased towards "My MUDs" Wink

as "My Sessions" does not have the quick association I have made with zMUD/cMUD and mudding.

Another advantage is that My Documents would be easy to back up. I have used one of those tweak programs to set My Documents folder on a shared drive. This has saved me quite a few times, when I had to reinstall Windows.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I completely agree with you. I've never liked the Application Data or Local Settings folders, just on the principle that they are redundant, hidden, and semi-undocumented. Making a My MUDs folder is more straightforward, easier to find.

Posted: Tue Jul 25, 2006 8:42 pm

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

My Documents\My Muds

sounds good. I'm not a big fan of the my Music/Pictures/Videos/eBooks/Games etc, but there's probably not a better place to put them
I always move the My Documents folder out of my profile anyway and onto a separate drive so I can keep it separate from the Windows installation
Maybe give an option during the CMUD install?

Also, it's nice to keep settings away from the program itself. And it'll make troubleshooting easier, since they'll be completely separate.

GURU Joined: 24 Sep 2000 Posts: 1237 Location: USA

MS is changing the default storage place for User files in Vista from 2000/XP's "C:\Documents and Settings" to "C:\Users". The logic is that 1, "Documents and Settings" contains spaces, and 2, it's 22 characters long, biting into the total length of a filename you can create under it.

That in mind, I like the idea of calling it just "Muds" or "CMUD" in whatever base directory you choose, just to keep life a little easier.

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

My documents! A good place, it means I can have a diff setup for each user account on my comp without worrying about 1 account changing the other! And its easy to backup too.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I would suggest putting the characters datebase file there as well. This may slightly inflate the numbers for icon downloads but will more then likely provide a much cleaner way for multiple people in the same house using the same computer to use CMud. My Documents\CMud.

The only possible drawback to that is those people that do not backup thier system ocassionally. As you experienced that folder can be overwritten during some forms of Windows reinstallation as well, so a few people may lose sessions and settings under those circumstances. One possible way to overcome this would be to prompt at first launch for each user where they want to store those files, and then put a small file in the app data area that records the path. A check would be needed to detect valid CMud files, when the user completes thier selection, as it is possible they are reloading after a clean system install.

Posted: Tue Jul 25, 2006 11:52 pm

Yes, it would also store the CMUD.INI file, character database file, and the various Map files, etc. Basically, anything that is normally written to the main CMUD directory at runtime would go to My Documents/Whatever instead. So no files in the main CMUD directory would ever get written/updated.

Hmm...when Windows XP prevents normal users from writing to the Program Files directory, is it just for creating NEW files, or does it also complain if you update an existing file. In other words, where should I put stuff like the MUD Database that might be updated now and then. Seems like you'd just want one copy of this database on the system, and CMUD installs the default database, but when you select the Get Update option to update from the MUD Connector, then it needs to write to the database file.

The reason I suggested "My Sessions" or just "Sessions" is that the new SSH client based upon CMUD will likely share the same directory. That's why I've been trying to remove as many references to "MUDs" as possible, to make the code easier to port to the SSH client. That's why you see stuff like "Session Properties" instead of "Character Properties" and stuff like that. In the SSH client, the "My MUDs" and "MUD Connector" tabs at the bottom of the main session screen get hidden so you just see the main screen with your session icons.

So, maybe "My Documents\Sessions" might be the way to go. Of course, this might be confusing since people might not associate "Sessions" with "CMUD" (or with CSSH for that matter (or whatever I end up calling it))

Not sure what to do about the issue where My Documents gets overwritten by the system. This has certainly happened to me and it was *really* annoying because I lost ALL of my digital photos stored in My Photos. I vowed that day to never use My Documents for anything! I'm not sure how prompting where to store files and recording the path would help. If they have lost everything in My Documents, and that's where the MUD files were stored, then they are gone. CMUD would just see the missing files and would recreate stuff like a clean session database from scratch just like from a fresh install.

Wanderer Joined: 25 May 2006 Posts: 88

Sessions is too vague, perhaps a folder within My Documents (or the equivilant in Vista) called ZuggSoft that way whether the user is using your Mud client or an SSH client they will know where the files are.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

A lot of new computer games store your save games in My Documents \ GameName or Application Data \ GameName

eg

c:\Documents And Settings\UserName\My Documents\GTA San Andreas User Files\
c:\Documents And Settings\UserName\Application Data\NFS Underground\

So I don't see why you wouldn't use c:\Documents And Settings\UserName\My Documents\CMUD User Files\ or something.

For your SSH product use c:\Documents And Settings\UserName\My Documents\zSSH User Files\ ... I don't see why you need to hardcode the path into the application, you can pull the application.exename and parse it to find out if it's CMUD or zSSH or whatever and append that to the My Documents path you pull from the Registry.

I'm not sure if I prefer the files to be hidden away or not - perhaps keep them in application data and have some kind of 'backup user files to...' and whack it into a zip or something on their floppy/USB stick.

If you plan to make it so they can double-click their sessions / character files then maybe leave it in the my documents, but if you aren't going to interact with the icons/files on a normal basis, I think it probably should be hidden.

Wanderer Joined: 13 Jun 2005 Posts: 51

I would prefer specific game database, map, settings in "My Documents\CMUD\SessionID", so I can easily transport to other computer.
Downloaded packages in "Application Data\CMUD".

Magician Joined: 29 Nov 2005 Posts: 482

as long as Zugg uses system pathing the change from xp to vista shouldnt make a huge deal

i.e

"%HOMEDRIVE%""%HOMEPATH%"\My Documents = is the users my documents in WinXP
"%HOMEDRIVE%""%HOMEPATH%"\Documents = is the users my documents in Vista im fairly sure.

so thats to be considered.

As to some of the other concerns. Crashes happen failures happen however with vista (it will move all the contents of a crashed vista installation to OLDWINDOWS or something folder before recreating) they stopped the overwriting of the system user folders. With XP well thats the same ole same ole. People should be backing up anyways. You might consider giving them that option.

File --> Backup Files (compressed format of some sort)

I am not sure if i want them in my documents myself. I have a lot of DOCUMENTS in there not program information but it seems like the most logical place if you are worried about accounts. Might i bring up a point though .. The accounts are limited for a reason and administrators and parents alike can choose too allow the program to run and update with simple permissions and or allowing of applications. They only need to install it and run it the first time. Circumventing that would also remove some of the benefits for "Parents" "Employers" etc for having limited accounts to prevent things like this.

Wanderer Joined: 13 Jun 2005 Posts: 51

I think the correct way to obtain folder location is using shell api SHGetFolderPath, and a list of CSIDL.

For delphi 7, it is declared inside SHFolder.pas.

by the way, in zmud current directory is keep changing, my log files are all over the place unless I use absolute path.

Posted: Wed Jul 26, 2006 2:13 pm

My Documents is the way to go definitely. As Rainchild suggested I think parsing the program name for the folder name is a good idea.

Zugg: The answer to your question about updates rather than writes is no a normal user cannot perform them. Hmm what to do about the mud list? Can your installer program change permissions, I know some can? If so I'd get it to do that.

Wanderer Joined: 13 Jun 2005 Posts: 51

A guide for XP to Vista for game.

Posted: Wed Jul 26, 2006 5:18 pm

Yejun: That's an interesting link. I hadn't heard of the Game Explorer in Vista before. It's probably something I'll eventually support with CMUD, but not right away. I'll have to do a lot of testing and research to see how it really works.

Taz: Thanks for the info on updating files. I'll check the NIS installer and see if it can set file permissions.

Edb: I understand the issue with parents and employers, but it seems like just requiring Admin to *install* the application would be good enough. Doesn't seem like it is necessary to have the Admin actually run CMUD the first time. But as I said, I don't yet know what's really needed for the copy protection I'm using. I know that with eLicense it *must* be run the first time using Admin to set up the eLicense system. I don't have as much experience with Armadillo yet and it would be nice if there was a way to avoid forcing the Admin to run it.

Also, as far as determing the location of My Documents, that's easy. As mentioned, I just use an SID to locate it. I don't need to hardcode any path names or anything. And I'm sure Vista uses the same SID even if the name changed from "My Documents" to just "Documents". So that change *should* be transparent to my code.

I think the trickier part is adding code to the installer to tell it where your old zMUD files are so that the installer can copy them to the new CMUD directory structure in My Documents. CMUD needs to see your existing zMUD *.MUD files in order to convert them to PKG files the first time you load a session. I don't want some long and involved conversion step when installing CMUD. I'd like it to work the way it is supposed to now: when CMUD first loads your MUD character, if the primary settings file points to a *.MUD file then it gets converted on-the-fly to a new PKG file and stored in the same place as the previous MUD file. So if the installer just copies your current zMUD files into the My Documents/CMUD area, then everything should work fine.

For now, I think I'll keep the MUD database and any other file that gets modified in the "My Documents/MUDs" folder as well. This will save me from any permission issues. If it means that multiple users each have their own MUD database file, oh well, it's only 3MB.

Each character session will still be in it's own subdirectory, just like with zMUD. So, for example, if you were playing on Medievia, then your character file would be in "My Documents\MUDs\Medievia\Medievia.pkg". Maps would still be in the Maps subdirectory, databases in the DB subdirectory, etc. The global files such as CMUD.INI and the Muds.db and Sessions.db files, and any local spellcheck dictionaries would be in "My Documents\MUDs".

The downloaded package files that are available for all characters would be in "My Documents\MUDs\Packages".

Gee, that doesn't leave a whole lot stored in Program Files, does it.

Magician Joined: 29 Nov 2005 Posts: 482

all they have to do is allow the program to be used and you have no file permissions issues or if its run in the context of RUN AS --> User

Or as someone else noted change the permissions of your CMUD/ZMUD folders to full permissions in your installer.

I personally will just end up copying cmud right back out of my documents because i dont want it there and never would. I put all my personal and business correspondence etc in there. I like it right where it is. All parts of a program in 1 folder not 3 or 4.

Many other companies get their products working just fine on limited and admin accounts alike. Some programs can be installed just fine either way. You MIGHT have to in the end go with a more advanced installer script. As to armidillo it doesnt matter which account you run it on i dont believe. All its changes are based on a fully writable set of files keys and permissions. I dont think admin vs limited had any bering there. As i said i have it running on a limited vista and xp account and admin account both just fine well aside from the obvious bugs :P

From Vista Documentation itself

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Hrm, I've decided I don't like "My Documents" at all, its not like CMUD settings are a spreadsheet or word document, and what happens if I have My Documents\MUDs\mydescription.doc and so on... you're going to clutter up that directory which potentially has real documents in it?

I'd definately prefer the files in \Application Data\CMUD but I can understand that some people may forget to backup that directory when upgrading their PC so if you are going to store files in the My Documents directory, then pick something more unique than 'MUDs'. Maybe 'CMUD Settings' or something?

Magician Joined: 29 Nov 2005 Posts: 482

or just offer a file extensions

File
--------=> Backup Cmud Files.

That puts them into a rar format for example and spits it out for the user to save where ever he/she wants. Seems like the best type of backup plan. If someones computer crashes then they can always import the settings back in. Just put a note in the help file regarding the location. or an option to import backuped up files.

Any pc migrator/pc repair shop worth their weight is going to know that when backing up users (in xp, vista is even easier) to copy the application data because thats where things like your outlook mailbox, contact lists, address books, firefox extension lists, thunderbird email etc are.

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

Microsoft has a tool here that, among other things, helps you identify what parts and processes of your application would specifically have trouble running under LUA (now called UAC). They also have a page with some best practices to follow for UAC compliance. You probably already know all of this, but it probably wouldn't hurt to go over them quickly.

As for what to do, with the placement of package files, I really don't see a truly satisfactory solution. I hate when programs store files that I would want to access myself under ApplicationData. Azureus does this by default by storing the .torrent files inside this directory and I hate it. On the other hand, I also hate when applications create directories inside the My Documents folder. I like to manage this folder myself with only the specific directories I want there. Also, I tend to view this folder as a place that would not hold configuration files for any application. For example, I could choose to put CMUD's packages there (it would have to be my election not CMUD's), but not the MUD database. So I can't think of a proper solution to remove CMUD's dependancy on writing to Program Files.

Perhaps what could be done is to sacrifice a bit user-friendliness here. When a new character is created, ask the user where they would like to place the package files and don't default to Program Files. This way, the user will know where the package files are and what to backup. You would also need to ask for a default download directory for downloaded packages and CMUD could ask for this the first time a package is downloaded. The character database is trickier. If you want each Windows account to have a separate set of characters, then it would be handled like packages. Otherwise, it would be handled like the MUD database and INI files. The MUD database and INI files would remain under Program Files in Windows XP. For Vista, however, they would be migrated (or created if it is a clean CMUD install) into the \Users\(Account)\AppData diectory. I have not checked yet if this directory is hidden by default, but I'll check at work today. If it is hidden by default, then you could leave them in Program Files, and use the Vista UAC UI to ask the user for permission whenever you need to write to these files.

Posted: Thu Jul 27, 2006 4:55 pm

I have an idea I bet no one will like.

Put the entirety of CMUD into My Documents.

Might be some redundancy on backups if alot of different users on the same system use it, but even still, it doesn't take up THAT much space.

There would be no question of if the user is allowed to write there.

It would solve the sharing of licence concern as well, no?

Posted: Thu Jul 27, 2006 5:17 pm

See, this is getting more and more complicated. I hate stuff like this. Even if Vista improves the default directory structure, we still have to deal with Windows XP since the majority of people will continue using XP for many years.

Now you understand why I used to just default the installer to put zMUD into C:\zMUD and forget about all of this Program Files and Application data crap.

But the problem with just putting everything into C:\zMUD is that it doesn't handle multiple users on the same computer who want their separate settings. Installing zMUD to Program Files didn't fix that problem, and just added the complexity of limited users not having write permission to the Program Files directory.

I agree that I don't like the idea of cluttering My Documents. I also hate programs that add their own subdirectories to this folder. But I also hate programs that use the Application Data area since a) it goes to my system disk instead of my user disk, and b) the directories are hidden which makes finding stuff a big problem for some people. I've seen Support Forums for software that puts stuff in the hidden Application Data folders and it becomes a huge support issue. The last thing I want is even more support email.

So, I'm afraid that the Application Data area is out. I just don't want to deal with users who can't see hidden directories and can't find any of their MUD settings.

I'm leaning towards My Documents even though I don't like it, just because it's the only reasonable way I can see to separate settings for multiple users.

However, don't worry, I'm not going to force this on everyone. What it means is that I need to improve the design of CMUD to allow "Data" files to be in a different location from the "Program" files. You can certainly STILL decide to make these the same directory. In other words, when installing, it will ask you where to install the program, just like it does now. It will probably still default to "Program Files\CMUD". But then the installer will ask a SECOND question about where to place user settings files. This will probably default to "My Documents\CMUD" but you can still CHANGE this to point to "Program Files\CMUD" or just C:\CMUD if you want.

I think the flexibility of handling settings in a different location that the program is worth implementing before the public release. This doesn't mean that you are forced to split your files, but it means that CMUD has the flexibility and can therefore better handle multiple users and limited user accounts.

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

I just checked and it seems that \Users\(Account)\AppData will be hidden by default in Vista. So that directory will be out of the question too.

Seems like it will have to be My Documents then. Could you make the installer ask the question that others installers ask about that directory not existing and if the user would like to create it? This might be a bit more annoying, but would probably get you less people complaining about not noticing that the installer created that directory.

Posted: Fri Jul 28, 2006 8:40 pm

Sorry, but I see no reason to not store it in CMUD/Mud_name/Player_name