[misterhouse-users] Re: MH installation directories

[Amauri V. <am...@vi...>]

David Norwood writes: 

> It's unreasonable to expect the script to handle upgrades for the installed
> userbase.  If an existing user wants to use the install script, they will
> need to install in a new folder and manually move their custom files over.
> This won't be hard for most misterhouse users. 
> 
> It would be best if the default installation folder was in Program Files,
> like a real Windows application.  I know Bruce recommends against this
> because the space in name will screw up some scripts, but I bet we could fix
> those problems or use "progra~1" as a backup.

I know that personally I wouldn't want to deal with the 8.3 name, as it 
makes it seem like more of a "hack" than anything else.  I've come across 
problems using the space, and the directory structure on something like 
XP/Win2k is just painful to look at... All your data files would be 
somewhere under "c:\documents and settings\[username]\misterhouse\data", for 
example... :) I agree that it's easier for backups and what-not, but it 
always seemed "neater" to keep it close to the application itself.  I don't 
know, I'll go with whatever (if anything) is decided.  I'm just pointing 
things out as I see them. 

We could also try and get away from hardcoding some of the paths into the 
.ini file by using environment variables (like %userprofile% or %appdata%) 
but I don't know how much work that would require as far as changes to the 
core MH stuff itself. Not to mention that testing now becomes a pain because 
we have to deal with something like a dozen different versions of Windows... 
:) 

> I'm not convinced it is worth the added complexity for the install script to
> juggle different versions in different directories.  Users don't expect that
> anyway.  Usually, if you need to go back to an old version, you just
> re-install it.  Besides, aren't the new bugs always more fun than the old
> ones  :)

So you're saying take an approach more of pre-packaged installations that 
overwrite all of the MH components (except for the user-specific data, of 
course :) during installation.  If the user wants to go to 2.80 he installs 
the 2.80 package and that's it... rolling back should then just be a matter 
of installing the previous version and not worrying about legacy stuff. 

Sounds good and simple enough to me... The only problem that I see with that 
is if somebody doesn't actually want to have to install a new version 
(effectively removing their current working version) to test it, then 
finding out that they don't like something and have to re-install the 
previous version on top.  Not sure how big that audience is, but I guess we 
can always wait for more feedback and see if anybody has any ideas about it. 
:) 

>> Not sure where this is leading, but let me know if you need some help with
>> packaging Windows stuff.  That's one of the few things I do well, so if we
>> ever decide on direction maybe I can lend a hand.
> 
> Sounds like a volunteer!

GAH! :) 

Give me a couple of days to come up with a test package. I have the tools 
and everything I need at home, but being the season that it is, I don't 
exactly have a lot of time to mess with things on the side.  :)