Zugg Software :: View topic

Apprentice Joined: 03 Nov 2007 Posts: 132

Alright, there is something definitely off in terms of installing CMUD on Vista. I am going to test it further today but I have followed all default installation instructions and my virtual store is *still* getting populated with CMUD data. I have a cmd.db file in my virutal store with a create date of 11/17/2007.

I also know other people are having this problem as well as I've had to walk at least two others through finding and getting rid of old cmd files. This is especially noticeable with Vista users who had 1.34 since there are so many new commands in the 2.x versions.

I have not pinpointed exactly *when* files are getting written to there but they definitely are.

Posted: Thu Nov 29, 2007 5:27 pm

The only time the cmd.db file is "written" is during the installer. Maybe the installer isn't running as Admin on your Vista system for some reason? Vista is supposed to run anything with the words "setup" or "install" in it as Admin by default, so maybe that option got turned off on your system somehow?

I'd be really interested in getting some more testing of this. Install 1.34 and then upgrade to 2.13 to see what happens. I certainly don't want to get flooded with installation problems when the 2.x public version is released. But I'm not getting any files in the virtual store on my Vista system here, so I don't know what to do about this.

Maybe it's a difference between Vista Home (which you are using) and Vista Business (which I am using)??

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

No real difference between Home and Business from what I know of, especially if you're not joined to a domain (with roaming profiles etc).
I was fairly certain that there was a difference to running even setup.exe normally and running it with UAC off or with the 'Run as Administrator' command. If you run as an admin or without UAC then nothing gets written to the store. I'd think from a testing POV you want to first uninstall everything, then turn UAC on and try installing first 1.34, then 2.13 without selecting 'run as admin'. Then once you've tried that uninstall it all again and try with 'run as admin', then lastly with UAC disabled. I'd expect any virtual store problems to occur the first time round.

Apprentice Joined: 03 Nov 2007 Posts: 132

I will clean everything out tonight when I get home and then do some install testing. I haven't touched my default Vista settings really since July when I got the computer. I just cleaned out the whole virtual store which was an exact copy of my mygames/cmud folder. I wonder if this might be a reason for the access violations I'm having. Like the program is confused as to which files its supposed to using or something? I dunno. We'll see!

Wanderer Joined: 09 Jun 2006 Posts: 62 Location: Florida

Nothing gets written to the virtual store unless files are attempting to be written to a privileged directory (IE program files and all subdirectories, for example) and do not have elevated status. In this case, the virtual store puts these files in there. I could be wrong, but I am reasonably certain that one cannot 'disable' UAC's asking for elevation on any apps with 'setup' or 'install' in the name of the file. If, for some odd reason, that isn't happening, right-clicking the file and running as administrator will have the same affect anyway.

This is the reason why installing with the data files put in Documents\games\CMUD (Or whatever it is) is necesarry, because you can then run CMud without elevating it. You could still easily install all files to the Program Files\CMud folder, including data files, and just run it as administrator and it would have the exact same effect, but why run something as admin when you don't have to? :)

Posted: Thu Nov 29, 2007 7:08 pm

Right, but what I'm worried about is the installer itself. The installer *must* write files to the Program Files area, and we do not want the installer to be putting files into the virtual store. So the installer needs to be elevated. I don't care if it prompts the user for elevation or not. I thought I understood that having "setup" or "install" in the name would cause the installer to get elevated. If the installer isn't elevated, then there are definitely going to be problems. People shouldn't need to use "Run as Admin" for an installer program, so I need to find a way to ensure that the installer runs elevated (whether it prompts or not I don't care).

Geez, could Microsoft make this any more of a pain?

Apprentice Joined: 03 Nov 2007 Posts: 132

Well I was curious so did this on my lunch break. Here are my results with the summaries up top and the details below:
----
It looks like if you run just a normal installation of cmud, you will get the Virtual Store CMUD folder. Further, new installations will not overwrite the old folder and you will end up with your newly installed CMUD reading off the old .cmd file causing command problems (and who knows what else!)

If you run with UAC off, it installs fine and never creates a Virtual Store CMUD folder. No problems with upgrading and the like.

If you save it and run as administrator you WILL get a Virtual Store CMUD folder but it will update it properly when you upgrade. Assuming you run the upgrade as administrator as well.

UAC On

1.34

Click on the download link on Zuggsoft
Click run instead of save
Click allow at the windows requesting permission
Install using default locations
Look in virtual store - no cmud folder
Open cmud 1.34 via the "Launch cmud 1.34" option at the end of the install
Open up the Lusternia session
Close Lusternia session and cmud
Look in virtual store - cmud folder! Contents: cmd.db, default.pkg, and my .adu file
Uninstall CMUD, cmud folder remains in program files. Contents: help and packages folder and .adu file
virtual store cmud folder remains
start menu folder remains
mygames/cmud folder remains

2.13 (computer in same state as last described above to help simulate general user usage)

Click on the download link on zuggsoft
Click run instead of save
Click allow at the window requesting permission
Install using default locations
Look in virtual store - same cmud folder with same cmd.db, default.pkg, and .adu file as were in there for 1.34
Open cmud 2.13 via the "Launch cmud 2.13" option at the end of the install
Look in virtual store - same cmud folder with same cmd.db, default.pkg, and .adu file as were in there for 1.34
Open lusternia session
Type #THREAD to make sure command is working. It is.
Close lusternia session and cmud
Look in virtual store - same cmud folder with same cmd.db, default.pkg, and .adu file as were in there for 1.34
Open cmud and lusternia session
Type #THREAD. Get the following error window: Error parsing command: invalid command: THREAD
Close cmud and lusternia session
Look in virtual store - same cmud folder with same cmd.db, default.pkg, and .adu file as were in there for 1.34
Delete cmud folder in virtual store
Open cmud and lusternia session
Type #THREAD. Works fine
Look in virtual store - new cmud folder with cmd.db, default.pkg is created. File dates are from november instead of april

Uninstall everything and delete all CMUD folders.

UAC Off

1.34

Click on the download link on Zuggsoft
Click run instead of save
Install using default locations
Look in virtual store - no cmud folder
Open cmud 1.34 via the "Launch cmud 1.34" option at the end of the install
Open up the Lusternia session
Look in virtual store - no cmud folder
Close Lusternia session and cmud
Look in virtual store - no cmud folder
Open cmud and Lusternia
Create an alias and two variables. Save settings.
Close lusternia session and cmud
Look in vritual store - no cmud folder
Open cmud and Lusternia. Connect to mud. Close Lusternia and cmud
Look in virtual store - no cmud folder
Uninstall CMUD, help and packages folder remain as well as .adu file
Look in vritual store - no cmud folder

2.13

2.13 (computer in same state as last described above to help simulate general user usage)

Click on the download link on zuggsoft
Click run instead of save
Click allow at the window requesting permission
Install using default locations
Look in virtual store - no cmud folder
Open cmud 2.13 via the "Launch cmud 2.13" option at the end of the install
Look in virtual store - no cmud folder
Open lusternia session
Type #THREAD to make sure command is working. It is.
Close lusternia session and cmud
Look in virtual store - no cmud folder
Open cmud and lusternia session
Type #THREAD. Works fine
Close cmud and lusternia session

Saving cmud install file and then explicitly running the saved file as "Run as administrator"

1.34

Click on the download link on Zuggsoft
Click save
When finished with saving, find the saved file, right click and select "Run as administrator"
Click the "continue" when it asks for permission.
Install using default locations
Look in virtual store - no cmud folder
Open cmud 1.34 via the "Launch cmud 1.34" option at the end of the install
Open up the Lusternia session
Close Lusternia session and cmud
Look in virtual store - cmud folder! Contents: cmd.db, default.pkg, and my .adu file
Uninstall CMUD, cmud folder remains in program files. Contents: help and packages folder and .adu file
Virtual store cmud folder remains
start menu folder remains
mygames/cmud folder remains

2.13

Click on the download link on Zuggsoft
Click save
When finished with saving, find the saved file, right click and select "Run as administrator"
Click the "continue" when it asks for permission.
Install using default locations
Look in virtual store - same cmud folder but only old default.pkg in there
Open cmud 2.13 via the "Launch cmud 2.13" option at the end of the install
Look in virtual store - same cmud folder but only default.pkg in there
Open lusternia session
Type #THREAD to make sure command is working. It is.
Close lusternia session and cmud
Look in virtual store - same cmud folder but new default.pkg and new cmd.db files in there
Open cmud and lusternia session
Type #THREAD. Works fine
Close cmud and lusternia session

Posted: Thu Nov 29, 2007 8:09 pm

Hmm, it looks like your example is showing that the Virtual Store stuff is being created when CMUD runs, and not by the installer. That is very interesting. I'm not sure why it is doing that since I didn't think CMUD was ever writing the cmd.db file. So I don't know how that file gets put into the Virtual Store. I guess I'll need to read more about why the virtual store is doing this (and why it's not happening on my system with UAC on).

It also looks like the installer is not getting elevated to Admin privs.

Can you rename the CMUD installer from CMUD134install.exe to setup134.exe and change CMUD213install.exe to setup213.exe and see if that makes any difference?

Apprentice Joined: 03 Nov 2007 Posts: 132

Okay, will do that a bit later

Posted: Thu Nov 29, 2007 8:17 pm

OK, I might have determined part of the problem. When CMUD opens the CMD.DB database, it opens in read/write mode. And even though it never writes to the database, since it *can* write to the database, Vista apparently moves it to the Virtual Store.

I have fixed 2.14 so that it opens the CMUD.DB database in readonly mode. Hopefully this will prevent this problem in the future.

Unfortunately, I don't see any way to fix it for people who already have v1.34 installed and already have stuff in the Virtual Store. Maybe I need to somehow delete the CMD.DB file in the virtual store within my installer when it installed v2.13?

Apprentice Joined: 03 Nov 2007 Posts: 132

If you can delete that cmd.db file, that seems the way to go. I can see a lot of 1.34 users having problems with this.

Posted: Thu Nov 29, 2007 8:55 pm

OK, I have modified the installer to delete the file:

$LOCALAPPDATA\VirtualStore\Program Files\${PRODUCT_NAME}\cmd.db

The $LOCALAPPDATA in the Nullsoft installer should point to the C:\Users\username\AppData\Local\ directory wherever it might be located. The ${PRODUCT_NAME} is CMUD in this case. I ran it on my system and it seemed to work. And it doesn't give an error if the file or directory doesn't exist, so I don't think I need to even check for Vista systems.

If anyone has any alternate suggestions, let me know.

I have also moved the DEFAULT.PKG file into the /packages directory (where it should be anyway). I have also fixed the Addict spellchecker so that the *.ADU and *.ADL files for user-defined dictionaries get stored into the DataDir location properly. I'll also make sure the help system is using the file in the correct location.

But the CMD.DB file is the only one I'm going to delete from the Virtual Store.

Sorcerer Joined: 13 Jan 2006 Posts: 715

I really hate Vista,
But to help further this, I've done it on my Vista Home Premium to test as well, and I've gotten somewhat different results. However I've done this on the fly. When I have time later, I'll follow Malach's steps exactly on mine, and see what happens. However, it does seem right now that with UAC on, it puts stuff in the store, EVEN if you run the installer AND the program with the Run as Admin option.

Posted: Fri Nov 30, 2007 10:16 pm

I've also decided to go ahead and delete the existing DEFAULT.PKG file from the VirtualStore. I remember some people having trouble in the past where deleting the default.pkg fixed it for them. So it occurred to me that someone might get a corrupted default.pkg file that is stored in their VirtualStore and then reinstalling CMUD wouldn't fix it. So in 2.14, both the DEFAULT.PKG and CMD.DB files will be deleted and replaced by the installer. They will also be deleted by the Uninstaller.

Sorcerer Joined: 13 Jan 2006 Posts: 715

Well, with further testing I can verify Malach's results. I'm getting the same behavior using windows vista home premium. With 2.13 of course :)
But my UAC is back to off, and I'm going to upgrade to 2.14 tomorrow.