176116 - Make Windows App Paths aware of GRE\bin location

Status: RESOLVED INCOMPLETE

(SeaMonkey :: Installer, defect)

Description

[[e-mail] (away - not reading bugmail)]

This is a spin off from bug 167610. When installing a GRE application such as
the MFCembed browser, we need to make Windows aware of the GRE\bin location.
This can be achieved via registry App Paths, which seems preferable to a launch
batch files solution.

Here are some of the pertinent comments from bug 167610:

------- Additional Comment #12 From Curt Patrick  2002-10-19 20:53 -------

Well, we kind of overlooked the need to update the batch file which launches
MfcEmbed (runapp.bat) with the path to gre.  Upon reflection and discussion,
however, I think we are going to update the AppPaths setting in the Windows
registry instead of modifying the batch.  This will make any links to MfcEmbed
work, although I don't think we will then be able to launch MfcEmbed directly
from a DOS window.  So, looks like we need to deal with three steps here:

1) The MfcEmbed install script needs to set the AppPath registry setting.
2) We need to provide an icon for MfcEmbed.  On the desktop, I presumed?
3) Do we want to remove runapp.bat from the distribution completely?


------- Additional Comment #13 From [e-mail] 2002-10-19 22:45 -------

"start" is your friend, it's aware of apppaths.


------- Additional Comment #14 From [e-mail] 2002-10-20 03:02 -------

timeless, I was going to put the GRE app path under the key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\mfcembed.exe and verified on Friday double-clicking on the mfcembed.exe
icon anywhere in the Windows GUI will work as desired. 

mfcembed.exe cannot be launched from the command line though and I haven't found
any other way of dealing with that issue except messing with the PATH
environment variable.


------- Additional Comment #15 From [e-mail] 2002-10-20 03:07 -------

Curt, would it be more logical to have the GRE installer add the AppPath
registry setting? It should know the app exe path and it also knows its own
location. This might resolve the sequence (install MFCembed *after* installing
GRE not prior to it) issue we touched upon on Friday.


------- Additional Comment #16 From Curt Patrick 2002-10-20 20:48 -------

Lets see if Sean will weigh in on this.  

I guess the choices are 1) Install GRE first so the app can know the GRE path is
when it sets the AppPath variable or 2) have GRE set the AppPath variable.  The
third possibility, have the app use the same logic GRE will use to predict where
GRE is going to be installed, seems inherently unsatisfactory.  I'm a bit
uncomfortable with GRE making settings for the applications.  Seems like other
applications might not want control over that variable.  Hmmmm.....I guess we
could make this yet another command-line option to the GRE installer, huh?


------- Additional Comment #17 From [e-mail] 2002-10-21 05:18 -------

jbetak: maybe i wasn't clear. if double clicking works, then using start will

too.

in a prompt type: start mfcembed.exe

it checks app paths in order to find things, just like explorer.


------- Additional Comment #18 From [e-mail] 2002-10-21 07:10 -------

timeless- cool! That'll do :-)

Comment 1

[Charles Rosendahl]

I believe this is not the case.  

Looking at the spec on mozilla,
http://www.mozilla.org/projects/embedding/MRE.html, There are code fragments
that applications are supposed to use to get the correct version of the GRE that
they depend on.  System variables and GRE specific location literals are not
desirable.

I actually think in this case, MFCEmbed needs to be rewritten to pull in the GRE
location that it needs from the registry values stored in the GRE version keys
upon which it depends, as the doc in the url above points out.

Comment 2

[Charles Rosendahl]

Never mind - apparently the apps in the spec are relying on the App Path value
or something else external to the application to configure the runtime
environment settings.

Unfortunately, this means that multiple versions of the same app (i.e. AOL7,
AOL8, just as an example - since I only see aol.exe once in the list) may use
the same app path setting when they shouldn't be.

Comment 3

[[e-mail] (away - not reading bugmail)]

right, that is a serious limitation of this approach and I don't have a good
solution for that yet.

Comment 4

[Curt Patrick (gone)]

Actually, Charles, you have hit upon an issue that Syd recently raised with me.
 Our current Windows registration schema doesn't allow for multiple copies of a
GRE dependant application to be installed one the same machine.  That probably
isn't acceptable.  I've been thinking about how to remedy that problem.  Feel
free to open a bug to keep me honest.

Comment 5

[Charles Rosendahl]

reassigning to sean, as this is part of a larger issue to deal with the app_path
registry setting, etc....

Comment 6

[Rafael Ebron (:rebron)]

Installer triage team: nsbeta1-

Comment 7

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 8

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 9

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 10

[Robert Kaiser]

old XPFE installer is dead.