Patch X32 to X33 Autoupdater installed without eny problems ON Win Vista Ultimate

I'm not on vista but

I have this in scripts/autoexec.lfs
/insim 29999

after LFS is updated, when it restarts the application it shows this:
InSim - TCP : bind failed
InSim : not initialised

and it's not possible to re-initialise it with /insim 29999 - same error

Scawen, Vista huristics identifies files including the word "update" (and possibly others too) as installers so it requires administrative rights to run them. If the file you try to run is similar, then that might be the reason. Another option is to run it using ShellExecute instead of CreateProcess. it uses different and not as tight huristics, although that can change in the future I guess...

Thanks, that's interesting.

At the moment I just use _spawnl when LFS starts the restarter, and _spawnl also for the restarter to unzip the self extracting patches.

I've just been trying to do some research here based on what you said (I'm running out of time but just thought I'd have a look). It's a bit confusing with all this "elevation" and things, and using "runas" as a verb to request elevation and so on.

Should LFS request elevation of the restarter program when it runs it? Or could that even make the UAC come up when it wouldn't have done so? Right now I think LFS can successfully start the restarter program, but it goes wrong when the restarter tried to execute the patches. Let me know if that's not the case, anyone!

So where should ShellExecute be used instead of _spawnl ? Is it when LFS starts the restarter, to give the restarter more priviledges? There seems to be one problem with that, it seems to me Vista might do a popup at that point, which could be bad if LFS is full screen.

Or should LFS stay unchanged, and instead, ShellExecute be used by the restarter program to execute the patches? It's fine if a dialog pops up at that point, because LFS has already exited.

Sorry if I sound a bit confused, it's because I'm... confused!

Quote from avih :

Vista huristics identifies files including the word "update" (and possibly others too) as installers so it requires administrative rights to run them.

You can add a manifest to the program resources to mark yourself as Vista-aware, to avoid being elevated as a suspected legacy installer. Though isn't it possible the updater still needs admin rights, to be sure it can update the EXE? Vista won't let normal users write to Program Files, if it happens to be there, except for more legacy handling where writes are written to a shadow file store.

I found it was better to add manifests to everything and solve any permission issues. There's too much compatibility magic happening with non-Vista aware programs, which can often mask real issues. Might be a bit late to consider for patch Y though!

Quote from alxf1 :

I'm not on vista but

I have this in scripts/autoexec.lfs
/insim 29999

after LFS is updated, when it restarts the application it shows this:
InSim - TCP : bind failed
InSim : not initialised

and it's not possible to re-initialise it with /insim 29999 - same error

OK I've fixed that. You will still get that error when you update X37 to X38. but it will be ok when you update X38 to X39.

Quote from obobo :

You can add a manifest to the program resources to mark yourself as Vista-aware, to avoid being elevated as a suspected legacy installer. Though isn't it possible the updater still needs admin rights, to be sure it can update the EXE? Vista won't let normal users write to Program Files, if it happens to be there, except for more legacy handling where writes are written to a shadow file store.

I found it was better to add manifests to everything and solve any permission issues. There's too much compatibility magic happening with non-Vista aware programs, which can often mask real issues. Might be a bit late to consider for patch Y though!

Yes, I think I'll have to give up on this one for Patch Y. That sounds like a whole new subject to learn. I don't even know what elevation means or what a manifest is!

Thanks you for the information.

It seems that Vista users appear to be able to get around the issues by giving permission, even if it's not done in a very tidy way.

There are some links there with more info about the manifest:
http://systemsengineering.word ... t-to-a-vista-application/

Vista shows a dialog when you start the app that contains the manifest (if you require higher privilege) and asks if you as the user wants to give the program the higher privilege.

all of my auto-update related problems were solved by running LFS.exe as an administrator every time.

(does not seem to work for me to simply be logged in as an admin and have UAC off)

I had Vista, I run my sesion as administrator (my brother has anothear sesion) and we had no problems with the updater or with the permissions. The firewall only block the conexion the first day, after a actualization it didn't ask for permision

Quote from Scawen :

It seems that Vista users appear to be able to get around the issues by giving permission, even if it's not done in a very tidy way.

Just a quick Vista overview... All Vista applications are launched with non-admin user rights by default, even if the user is a member of the Administrators group. Vista-aware programs can mark themselves as explicitly requiring or not requiring admin rights. For compatibility, any programs without the manifest resource that have "setup", "install", "patch" and other substrings in their filenames, along with a number of other conditions, will be assumed to require admin rights and will also be elevated. Elevation involves a confirmation prompt on a secure desktop, where the user must decide whether to allow it.

Normally LFS is run as non-admin and launches lfs_restart.exe with the same non-admin rights. Since that's causing problems, the patching process must require elevation to work properly (definitely true if it's installed to Program Files). Running LFS as administrator means the spawned updater also has the same elevated rights, so it all works.

The first part of the fix would be to add a manifest to lfs_restart.exe to ensure it's elevated when launched, even if LFS itself wasn't. However, launching the updater will need to use ShellExecuteEx (using the special "runas" verb) instead of _spawnl(), as the latter is internally implemented using CreateProcess(). Trying to create an elevated process from a non-elevated one causes CreateProcess to fail with ERROR_ELEVATION_REQUIRED.

However, there's one more gotcha! The option to restart LFS from the updater also means the game will be restarted as an elevated process! That may not be a problem, but it's probably best avoided. There's no standard or easy way to launch a non-elevated process from an elevated one, but it can be done by creating a scheduled task that executes immediately (yuck!).

I've been through a lot of it myself, so hopefully some of the above should be useful. The Vista Application Compatibility section on MSDN is worth a read...

Thanks for that info, I've added a link to my Vista reading notes!

bahh.. vista sucks. what's wrong with XP? probably the best OS MS came up with...
Seriously though, if you can avoid vista identifying the exe as installer, it's probably best since everything can run as non admin without any issues. Just have a vista computer near by, play with the file names till you find something that works. The worst case is that the user will have to download a new exe not through the update system, not very nice, but will work.