Spring RTS Engine

Download a separate TASClient and run it. It dosen't require administrator privileges. Disable Spring Downloader too...It downloads too slow. Before I was promoted to administrator I moved the entire Spring program folder to somewhere. I deleted Spring Downloader, and downloaded a separate TASClient, and it works.

It should not download slow unless you have crappy/ISP torrent throttled connection.
It uses all websites at once (except for jobjol) + peers. So if file is mirrored you are guaranteed to get better speed than normal web download.. and certainly better comfort.

I either take the 30 seconds to edit tasclient and SD in a text editor or run springlobby. What's so difficult about using springlobby if you're that worried about security? Hmm, right, can't get CA...

Is it possible to reliably trigger a UAC popup during execution after detecting the spring directory? The best I could find quickly was to load an elevated COM.

Joking and OS bashing aside, the correct location for Spring data is:

%USERPROFILE%\My Documents\My Games\Spring\

Which on my PC is:

C:\Documents and Settings\User1\My Documents\My Games\Spring\

This is the convention used by most new releases including CoH, FarCry2, Fallout3, Supreme Commander, etc (probably any "Games for Windows" title.)

Users can browser to this folder via My Computer->[username] Documents->My Games -or- Desktop->My Documents->My Games so it isn't as difficult to find as it seems at first glance.

As long as the change is coordinated with the lobbies and tools and the old locations are supported for backwards compatibility then this should help resolve most permissions issues.

Licho wrote:It should not download slow unless you have crappy/ISP torrent throttled connection.
It uses all websites at once (except for jobjol) + peers. So if file is mirrored you are guaranteed to get better speed than normal web download.. and certainly better comfort.

Recently I've had SD get to 80%ish then start going up & down.
e.g. 24.10MB, 24.02MB, 24.10MB, 24.11MB
It happens quite frequently, and I think others experience a slowdown as the download gets near 100% too, since some people say "only 20 seconds left on d/l", then 2 minutes later report that SD is still going.

There is no reason why springdownloader cannot download files and only ask for admin privs when it needs them to write to the folder.

Simply loading springdownloader should not need admin rights, neither should downloading to a user folder need them. Nor should uploading. You don't need to mess around with the manifest either it can all be done purely in code.

Also Vista without UAC is not the same as XP Pro. The network stack is far more secure, and the OS as a whole uses a much more secure design. The program files change was not a random idea they made up and has been official practice for a while now. They told everyone in XP it was supposed to be that way and were largely ignored, the linux people even touted it as a benefit over windows. Its a well established idea that has very good reasoning behind it and increases security quite a bit.

I am also baffled by the reaction to the suggestion any of the lobbies have bufferoverflows. Its nonsense to ignore or deny this since all programs have bugs. Just because we are not aware of them does not mean they don't exist. We're not all aware of all the code. Satirik has a lot of betalord code to go through and spring lobby is a multiperson project with various branches. Then theres TASServer and uberserver and all the bots etc etc ignorance is rife and we shouldnt dismiss it out of hand. Im not suggesting we go on overflow bughunts in a great big crusade though.

panzeriv2 wrote:Download a separate TASClient and run it. It dosen't require administrator privileges. Disable Spring Downloader too...It downloads too slow. Before I was promoted to administrator I moved the entire Spring program folder to somewhere. I deleted Spring Downloader, and downloaded a separate TASClient, and it works.

Really? When I join a game, by the time I type "hello" to the other players I have the map and I'm ready to go (unless it's a 60 mb map like mearth, then I'll need about 2 minutes).

YHCIR wrote:

Licho wrote:It should not download slow unless you have crappy/ISP torrent throttled connection.
It uses all websites at once (except for jobjol) + peers. So if file is mirrored you are guaranteed to get better speed than normal web download.. and certainly better comfort.

Recently I've had SD get to 80%ish then start going up & down.
e.g. 24.10MB, 24.02MB, 24.10MB, 24.11MB
It happens quite frequently, and I think others experience a slowdown as the download gets near 100% too, since some people say "only 20 seconds left on d/l", then 2 minutes later report that SD is still going.

Yeah i have encountered this one too Its a bug in torrent library im using (still under development). In such case i stop it and restart and it finishes rest quickly.

AF you are free to edit SD to ask for admin rights when its needed. I dont know how to do it.
Also tasclient might ask when it needs - but it needs it on startup to start SD :)

I'm not fixing your mistakes for you, google has the answers!

AF wrote:very good reasoning behind it and increases security quite a bit.

How?

Because malware cant modify or access the program files because its read only. In XP any old program can run and install itself in program files and modify its contents whether it be an windows update, installer, worm, trojan, or virus. This way only those programs that have business meddling in program files like updaters or uninstallers have access, and the user is made aware of it.

Its a huge security boost, and its one that has been standard practice on pretty much all non-windows machines for decades, to the point where some machines move that kind of stuff into Read only memory enforcing the policy at the hardware level ( though sometimes it saves money doing this )

Really, SpringLobby and TASClient both need a stable, separate executable app to handle their self-update program. That seperate app can require admin priveledges using a manifest.ini, and be invoked during the update process (to the user, that would make sense - "This program is trying to update itself, and thus is requesting admin permission", and otherwise runs in normal userland level.

TASClient's manifest.ini is particularly bad if you use it alongside SpringLobby or FileMover, since it can't find files that SpringLobby and FileMover put into the virtualstore.

@SpliFF

%USERPROFILE%\My Documents\My Games\Spring\

Which on my PC is:

C:\Documents and Settings\User1\My Documents\My Games\Spring\

The problem is that UAC lies to Spring about Program Files' writeablity. Various apps test Program Files for write-permissions and get a "yes" from the OS. UAC then re-directs those writes into the VirtualStore, which is a user-land (appdata\virtualstore\program files) folder that acts as a shadow of Program Files. So Spring apps try and be intelligent (write to Program Files if you can, write to the recommended user folder if you can't), but under Vista, they go into the Virtual Store.

It still _works_, but it's confusing to the user since this Virtual Store thing isn't exactly obvious.

Cirdan wrote:You seriously don't know??? Because the lobby open many inseure connections over the network, and i bet the lobby was not testet much against bufferoverflows and whatsoever.

I'd like to see a buffer overflow able to execute code in tasclient before it crashes tasserver, cause I'm almost completely certain it's impossible

Cirdan wrote:Hi!

ARE YOU NUTS?? Forcing users to running a game as Administrator is a HUGE security hole. Additionally many can not play it on machines where they dont have those priviliges in the first place, me included. So PLEASE, remove the enfocing entry from the manifest ASAP.

THX

Spring does not run as Administrator, certainly not in any install for any distro out there, and does not require to be run as Administrator. Get outta town. I never ran spring as Administrator, ever.

Wait. Are you using windows? ARE YOU NUTS?? Running Windows is a HUGE security hole!

Pxtl wrote:The problem is that UAC lies to Spring about Program Files' writeablity. Various apps test Program Files for write-permissions and get a "yes" from the OS. UAC then re-directs those writes into the VirtualStore, which is a user-land (appdata\virtualstore\program files) folder that acts as a shadow of Program Files. So Spring apps try and be intelligent (write to Program Files if you can, write to the recommended user folder if you can't), but under Vista, they go into the Virtual Store.

It still _works_, but it's confusing to the user since this Virtual Store thing isn't exactly obvious.

Don't blame vista for this, I don't think any programs here actually test for write permissions but just try anyway, which is the reason the virtual store was made in the first place.

lurker wrote:Don't blame vista for this, I don't think any programs here actually test for write permissions but just try anyway, which is the reason the virtual store was made in the first place.

the spring VFS does, so does unitsync, it would actually fallback to app data if only the write check wouldn't pass to program files folder with the UAC on

Brain Damage wrote:

lurker wrote:Don't blame vista for this, I don't think any programs here actually test for write permissions but just try anyway, which is the reason the virtual store was made in the first place.

the spring VFS does, so does unitsync, it would actually fallback to app data if only the write check wouldn't pass to program files folder with the UAC on

Okay, but I was really speaking of lobbies (especially tasclient with SD) and the archive mover, the programs that actually need to write data. If the archive mover tests for write permissions I'll be very surprised, considering it doesn't even check if you're copying a file to itself.

Also, we can update spring's manifest to one that marks it as vista-aware in seconds, if it always falls back correctly.

I think it would be even more annoying had it asked before each write/download than once on startup..

Then we agree it would be better to not ask at all (except maybe selfupdate)?