Author Topic: Adding OpenAL and wxLauncher to the FSO Installer  (Read 9982 times)

0 Members and 1 Guest are viewing this topic.

Offline Tomo

  • 28
Re: Adding OpenAL and wxLauncher to the FSO Installer
Fury mentioned a couple of assumptions that are no longer true:

Microsoft's design intent is that Admin permissions should be necessary to install anything on current Windows.
We can expect any remaining loopholes* to be closed, so the UAC prompt will be needed.

I believe that by default Windows 8 does not let you write to the C:/ root without admin permission, so C:/Games will already be 'broken'.
(Unsigned installers can also be painful under Windows 8, but we'll burn that bridge later)

Some installers change the rights during installation (eg Steam**), this is a good workaround for FSO - but obviously the installer needs elevated privileges to do that!

As you said, there has already been discussion about moving Pilot, config and log files into the user's Home folder somewhere. (Be that Documents or AppData/{GUID} or whatever)
At that point, the game itself will no longer require any write access to its binary and mod folders, which will be excellent.

Once that's done, the per-user data can be copied without recourse to grabbing the whole folder, and can even automatically 'roam' between different Windows computers.
Much smaller and easier.

* Windows 8's "Modern"/"TIFKAM" offers a peek into a future where files in the Users/ folder cannot be executed.

** Several Steam games do (try) to store their user data in their own installation folders, and Steam changes the ACLs during installation in an attempt to let them do that.
This is bad practice and doesn't always work, so some games need admin every time they run.

 

Offline Fury

  • The Curmudgeon
  • 213
Re: Adding OpenAL and wxLauncher to the FSO Installer
There's no reason we couldn't use that structure for new installs. If we can extract the GOG download on Linux and Mac, why not on Windows too?

But I still don't see much issue with having

C:\Games\FS2_Open (Where the launcher lives)
C:\Games\Diaspora
C:\Games\Freespace2

And people just copying all 3 if they want to move their FS2 install. In the end we're talking about something which most users don't do, and which you can't do with most games anyway.
In the worst case scenario the directory structure would look like this:
C:\FS2_Open
C:\Diaspora
C:\Freespace2

And if either installer or launcher would ever attempt to automatically parse mod and total conversion locations and versions so that the end-user does not have to, both would then probably end up searching all of C:.

It'd be much safer to have
C:\FS2_Open
C:\FS2_Open\Diaspora
C:\FS2_Open\Freespace2

That way both installer and launcher can safely parse the FS2_Open directory structure and look for mods, total conversions, executables and their versions and whatever else we may need today and in the future. End-user wouldn't even need to manually know or specify any of their locations.

Microsoft's design intent is that Admin permissions should be necessary to install anything on current Windows.
We can expect any remaining loopholes* to be closed, so the UAC prompt will be needed.
The difference being that anything related to FSO would not need install whatsoever, since nothing strictly requires admin rights. You only need to download (and extract) the files. It makes no sense to enforce this kind of behavior where it is not necessary!

I believe that by default Windows 8 does not let you write to the C:/ root without admin permission, so C:/Games will already be 'broken'.
That only applies to files, not directories. You can freely create directories under C:.

And as a general reply to your post. You seem to want installer/launcher to require admin rights even if end-user wants to update their mods or executables. Yeah no, thank you. First of all that would affect modders and fredders who could not longer even do as much as save missions without taking necessary permissions or be prompted by UAC. The whole point of improving this process is not to just make it painless to end-users who do nothing but play, but also fredders and modders. The fact that we'd have all sort of permission issues and UAC prompts kind of defeats that purpose. Yeah sure, the installer could manage the permissions for you during the initial install, but why when it's not even necessary to go that far in the first place. Seems kind of wasted effort.
« Last Edit: February 02, 2014, 11:02:51 am by Fury »

 

Offline karajorma

  • King Louie - Jungle VIP
  • Administrator
  • 214
    • Karajorma's Freespace FAQ
Re: Adding OpenAL and wxLauncher to the FSO Installer
In the worst case scenario the directory structure would look like this:
C:\FS2_Open
C:\Diaspora
C:\Freespace2

And if either installer or launcher would ever attempt to automatically parse mod and total conversion locations and versions so that the end-user does not have to, both would then probably end up searching all of C:.

It'd be much safer to have
C:\FS2_Open
C:\FS2_Open\Diaspora
C:\FS2_Open\Freespace2

That way both installer and launcher can safely parse the FS2_Open directory structure and look for mods, total conversions, executables and their versions and whatever else we may need today and in the future. End-user wouldn't even need to manually know or specify any of their locations.

In an ideal world, that would be great. But I don't know if you noticed my comment about Half-Life. Cause that's the situation we're actually in.

There is no way any Freespace Installer (Especially one which also deals with TCs) can know if the user has already installed FS2 (or an older TC) before the user downloaded the Installer. So then we're left with a problem. What do we do if the user has already installed Freespace to C:\Games\Freespace2 and TBP to C:\Games\TBP?
Karajorma's Freespace FAQ. It's almost like asking me yourself.

[ Diaspora ] - [ Seeds Of Rebellion ] - [ Mind Games ]

 

Offline Fury

  • The Curmudgeon
  • 213
Re: Adding OpenAL and wxLauncher to the FSO Installer
In an ideal world, that would be great. But I don't know if you noticed my comment about Half-Life. Cause that's the situation we're actually in.

There is no way any Freespace Installer (Especially one which also deals with TCs) can know if the user has already installed FS2 (or an older TC) before the user downloaded the Installer. So then we're left with a problem. What do we do if the user has already installed Freespace to C:\Games\Freespace2 and TBP to C:\Games\TBP?
I did notice that and I had answer prepared, but looks like it got lost in copy&paste. Well, let's try again. How does Steam handle pre-Steam retail editions of the games in Steam's portfolio? Short answer, it does not.

I don't think there is any decent and logical way to handle the situation in our situation either. Simply because the situation on any given user's computer could be anything, it would be purely impossible to take into account every possible scenario. Especially because said total conversions have had their own ways to install said total conversions.

But if this is something we have to attempt, then when it comes to retail FreeSpace2 the most the installer could do is to ask location of existing FreeSpace2 directory. Then proceed to merge it into agreed pre-defined directory structure as well as it can. If it notices anything it can't handle, it provides concise information what and why and then provides link to FSWiki article set up for these situations. The article would then contain instructions on how to manually resolve the problem.

But this would not work with total conversions that have used installers of their own, because they could have saved registry information pretty much anywhere. Then you'd also need to take into account uninstall information. In fact, it'd be simpler to merge the total conversion's data directory to agreed pre-defined directory structure, uninstall the total conversion and then have the installer re-install it. Luckily the number of total conversions the installer would need to check for is limited.

Or alternatively, parse only existing FreeSpace2 directory, merge it and don't support existing total conversion installations.
« Last Edit: February 02, 2014, 11:19:11 am by Fury »

 

Offline Tomo

  • 28
Re: Adding OpenAL and wxLauncher to the FSO Installer
You seem to want installer/launcher to require admin rights even if end-user wants to update their mods or executables.
No, I'm saying that Microsoft are slowly changing the enforcement of the rules, and it is inevitable that the Installer will require admin rights, if it doesn't already.
(And given some of the posts in the other FSO Installer thread, it looks like it might.)

Trying to find loopholes to remove that need is only going to cause pain, because sooner or later the loophole chosen will close and we're back where we started.

Best to accept that installation will need admin rights, and make sure that nothing else does.

People don't mind a UAC prompt to install or apply an update, but they will be very annoyed if they get that UAC every time they play the game.

But this would not work with total conversions that have used installers of their own, because they could have saved registry information pretty much anywhere. Then you'd also need to take into account uninstall information. In fact, it'd be simpler to merge the total conversion's data directory to agreed pre-defined directory structure, uninstall the total conversion and then have the installer re-install it. Luckily the number of total conversions the installer would need to check for is limited.

Or alternatively, parse only existing FreeSpace2 directory, merge it and don't support existing total conversion installations.
Good point, I think you're right about that.
« Last Edit: February 02, 2014, 11:38:09 am by Tomo »

 

Offline Iss Mneur

  • 210
  • TODO:
Re: Adding OpenAL and wxLauncher to the FSO Installer
1) Is there any way to build wxLauncher so that it can be a drop-in launcher with no installation, similar to the old Launcher 5.5g?

2) What exactly happens during the wxLauncher installation process?
In short:
1) No.
2) Mostly file extraction and copy.  It also registers itself with the windows uninstaller, notes its version information for future installers, and records the location of its command interpreter in the registry.

In long: The design ethos (as already noted in this thread) is for wxLauncher to be bundled with anything and everything just like steam is.  And like Steam, an installer that is installing wxLauncher on behalf of the user on Windows is expected to run the most recent version of our installer available from our download site at the time the installer is built for distribution.  It is up to the installer if they want to run the wxLauncher installer in silent mode (/S) or not.  It is safe to run the wxLauncher installer even if a newer version of wxLauncher is installed, that is, it will not downgrade the existing install.

wxLauncher does expect to be installed globally on the system.  So the wxLauncher installer will have to run as an administrator, which it will do automaticly if required.

wxLauncher expects the that an installer that wants to register a new total conversion will call the wxLauncher command interpreter and register it using the publicly committed api listed in the readme for content authors.  The full path to the command interpreter is located in the cmdinterpreter value under SOFTWARE\wxLauncher Team\wxLauncher.

For OS X and Linux I am not sure how well tested the command interpreter is, however the process is very similar, and there is no reason it shouldn't work because command interpreter is doing the same thing as the user would from the interface.  For OS X, wxLauncher expects the .app to be placed in the global /Applications directory.  An installer is expected introspect this .app and find the a file called cmdinterpreter with the execute bit set for the platform that it is running on or a the file wxlauncher with the execute bit set for the platform that it is running on.  On linux, it is expected that an installer will search for the file cmdinterpreter with the execute bit set in the /usr/share/wxlauncher directory or the file with wxlauncher with the execute bit set at /usr/bin/wxlauncher.  It is expected that the installer would then use the found interpeter the same as it would on windows.

An installer should never attempt to interact with the wxLauncher database stored on disk as the format can and will change.

EDIT: wxLauncher doesn't support win98 mostly because VS2008 doesn't.  To my knowledge wxLauncher doesn't do anything in particular that win98 can't support.
"I love deadlines. I like the whooshing sound they make as they fly by." -Douglas Adams
wxLauncher 0.9.4 public beta (now with no config file editing for FRED) | wxLauncher 2.0 Request for Comments

 

Offline Goober5000

  • HLP Loremaster
  • Moderator
  • 214
    • Goober5000 Productions
Re: Adding OpenAL and wxLauncher to the FSO Installer
The thing is, I can copy the wxLauncher setup program to the FS2 directory, same as the other executables.  But having to run the wxLauncher setup program is an extra step, whether I launch the setup or the user does.  And whoever runs it, the user is going to be faced with a UAC prompt.  No other feature or mod of either the Installer or any FSO executable requires UAC.

It would be a much smoother experience if wxLauncher was just a drop-in executable.  And aside from "registering itself with the Windows uninstaller", nothing in #2 intrinsically requires a setup program.
« Last Edit: February 03, 2014, 01:18:45 am by Goober5000 »

 

Offline The E

  • He's Ebeneezer Goode
  • Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: Adding OpenAL and wxLauncher to the FSO Installer
And that's a problem because...?
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline karajorma

  • King Louie - Jungle VIP
  • Administrator
  • 214
    • Karajorma's Freespace FAQ
Re: Adding OpenAL and wxLauncher to the FSO Installer
I don't see why an installer asking for elevated privileges is such an issue.
Karajorma's Freespace FAQ. It's almost like asking me yourself.

[ Diaspora ] - [ Seeds Of Rebellion ] - [ Mind Games ]

 

Offline pecenipicek

  • Roast Chicken
  • 211
  • Powered by copious amounts of coffee and nicotine
    • Skype
    • Steam
    • Twitter
    • PeceniPicek's own deviantart page
Re: Adding OpenAL and wxLauncher to the FSO Installer
because goober doesnt want any launcher that isnt effectively the 5.5 launcher?
Skype: vrganjko
Ho, ho, ho, to the bottle I go
to heal my heart and drown my woe!
Rain may fall and wind may blow,
and many miles be still to go,
but under a tall tree I will lie!

The Apocalypse Project needs YOU! - recruiting info thread.

 

Offline karajorma

  • King Louie - Jungle VIP
  • Administrator
  • 214
    • Karajorma's Freespace FAQ
Re: Adding OpenAL and wxLauncher to the FSO Installer
I doubt that's the case but if it is, he should have made his objections clear in 2009. :p
Karajorma's Freespace FAQ. It's almost like asking me yourself.

[ Diaspora ] - [ Seeds Of Rebellion ] - [ Mind Games ]

 

Offline Goober5000

  • HLP Loremaster
  • Moderator
  • 214
    • Goober5000 Productions
Re: Adding OpenAL and wxLauncher to the FSO Installer
And that's a problem because...?
To which point are you referring?


I don't see why an installer asking for elevated privileges is such an issue.
Because this particular installer is for the Launcher, which is separate from either the mod downloader or the GOG/FS2 installer.  It's a whole extra step, and it detracts from the smooth installation experience.

There's also the point that the credentials are required in the first place.  Suppose some kid wants to install wxLauncher.  One could conceive of a situation where the parent would consent to entering credentials for FS2 but not for "some unknown third-party program".

And this is aside from the fact that it is possible, in principle, to handle all of the points IssMneur mentioned without elevated privileges.

  

Offline Iss Mneur

  • 210
  • TODO:
Re: Adding OpenAL and wxLauncher to the FSO Installer
There's also the point that the credentials are required in the first place.  Suppose some kid wants to install wxLauncher.  One could conceive of a situation where the parent would consent to entering credentials for FS2 but not for "some unknown third-party program".
Having just installed FS2 using the gog.com installer, it also appears in the UAC the same way, because it is not signed either.  So said parent would have the same objection to that installer.

And this is aside from the fact that it is possible, in principle, to handle all of the points IssMneur mentioned without elevated privileges.
I have little doubt that we will address doing what we can without elevated privileges, but that is not something that has currently been designed nor tested.

Having said that, it is certainly possible to just copy all of the files that are in the wxLauncher folder with no ill effect on how the launcher runs, which is what Fury apparently does.  Though as Fury already noted, wxLauncher will still save the internal data to the users profile.  In this mode it will not be detected by the installer and the wxLauncher team doesn't support this installation mode.  Read, just copying will work more or less as expected but if it breaks its on you.
"I love deadlines. I like the whooshing sound they make as they fly by." -Douglas Adams
wxLauncher 0.9.4 public beta (now with no config file editing for FRED) | wxLauncher 2.0 Request for Comments