It looks like this might be a result of "startup.blend" being a critical startup file.

I recommend always installing a "virgin and read-only" copy of the startup files into the blender install directory, and then copying these startup files into a per-user blender config directory when the user launches blender for the first time. Among other things, this will make it possible to get a working blender if for some reason the per-user startup file gets messed up.

Sounds like UAC is striking back here :)

Blender uses the Application Data Directory instead the All Users Application Data Directory to store the startup.blend. The Application Data Directory is for the current user though. What is not this dramatic in Win XP, because it`s one click to unhide the hidden folders to grab what you need, becomes a problem in Win 7, where you need a hammer to convince Windows that you need access to the Application Data folder.

What would be neat would be to have the choice if the startup.blend installs in the current User`s Application Data Directory, or into the All Users Application Data Directory. Question is, is it wanted? It is surely lots of work because this means to fix and change lots of blender internal paths.

The blender installer hasn't been implement to work in multi-user scenario yet. Until then this is not really a bug, but rather a todo.

How does this work on Linux? Presumably the same situation occurs, where the root-administrator installs blender files in a common location, and then things like "startup.blend" and the .blend directory need to be instantiated each time on launch for a new user. It seems like it should work the same way on windows.

Everything works perfectly for multiple-users with the "choose install location" option "use installation directory" for the included scripts and startup files. I argue that this should be the ONLY option, but if not it should at least be the default/recommended option.

Blender is already designed to load scripts from the "immutable" installation directory, and still allow the user to put per-user preferences and scripts into their own AppData directory (like .blend on unix). I don't see any benefit to allowing this option in the installer. I could see having an option for blender to use $HOME/.blend instead of AppData for per-user config information (for example, if they share a network home directory between unix and windows machines). However, I don't see why you would install anything there in that case.

Uploaded a patch which fixes this by writing scripts to ProgramData.

Second patch, fixes Desktop shortcuts not being removed. Also made the uninstaller dialog messages a bit more clearer.

Are the options in "choose installer location" still present? If so, can you clarify what the purpose of each one is?

I still maintain that the install would be complete and fully functional with no options , and the behavior of the "use installation directory" option.

The options are still there. You can now choose to install scripts into the system application data directory (ProgramData), the user application data directory (AppData, this option will only create shortcuts for current user) or use the installation directory. the %HOME% option was removed as it didn't work with Blender and needs a lot more work/planning first.

What is the purpose of the options?

For example, what is the purpose of the option to install scrips into AppData? As far as I can see, all it does is make Blender not work for other users. The user can still put their own user-installed scripts in AppData either way.

I can see a purpose for installing ALL of blender into the user's AppData directory (as used to be the default in 2.56) because it allows non-administrator users to install Blender, but I don't see the reason for installing scripts to any location other than the place the EXE is installed. Can you explain?

You should ask a developer about that, I'm only trying to improve the installer. I think that we need two separate installation modes, one that installs Blender and scripts to AppData without any admin privileges, and another mode which installs Blender and scripts all into Program Files for all users to use. it does indeed seem pointless to install scripts to AppData with Blender being somewhere completely different.

Agreed 100%... It would be great if the installer were changed to have only those two options.

>but I don't see the reason for installing scripts to any location other than the place the EXE is installed.

You have to ask Microsoft here. In Win 98 and earlier you were indeed able to put everything besides the exe. Here it was really easy to develop. Then UAC gots introduced, and the UAC prevents to write to files that resides in the Programs Path, like Inis for example. You are forced to put Inis and equal files that needs writing access into the application data folder. Plus normal users are not able to read the Application Data from other normal users under Win 7. They are hidden. That`s where some of the problems with an empty UI comes from. You need to write to the Program Data folder here when all users should have access to the data.

All in all UAC is one of those nag features that promises to make the system more "safe" and "secure". All it does is to make the life of the users and developers harder ...

I'm working on a fix for this issue, initial patch here:
http://codereview.appspot.com/4529081/

The patch notes sound like a good direction....

As for the issue "compatibility with existing files installed in AppData"... I don't think much effort should be put into issues related to the 2.57 install.. Different version installs are already fairly incompatible with each-other (through the installer) because they all install into "ProgramFiles/Blender", overwriting the old EXE. As for the crufty script stuff that never should have been copied to per-user AppData, adding a patch note telling users to delete the old 2.57 AppData copy of the installed scripts is probably enough.

The better question to ask here is "What should happen when new versions of Blender are installed on the same machine?". It might be convinient if the installer put Blender into "ProgramFiles/Blender/Blender258" so multiple installs could coexist... Most programs allow for this by allowing a "custom install" option that lets you specify the application install location specifically.

I have commented on the patch by Brecht on http://codereview.appspot.com/4529081/

The patch looks good, with exception of the noted regression with portable installs.

Fix in svn, thanks for the report.