167610 - Plug gre installer into mfcembed installer

Status: VERIFIED FIXED

(Core Graveyard :: Installer: GRE, defect)

Description

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

mfcembed should be an MRE-based test application, we need to change the existing
mfcembed installer to include MRE installation/distribution

Comment 1

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

Seems like we could use RunApp to launch the GRE install, the only larger chunk
of work is getting the GRE install binary packaged into the mfcembed installer
distribution. I'll try to complete the work and post a patch later today.

Comment 2

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

preliminary config.ini changes

;RunAppX sections
[RunApp0]
Timing=pre launchapp
Wait=FALSE
Target=gre-win32-installer.exe
Parameters=-mmi -ma

Comment 3

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

Attachment: patch v 1 (contains parts of a patch from bug 171010)

Comment 4

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

Curt, your patches from bug 171010 helped a lot! The approach I took is fairly
simple and it seems to be working OK.

The only thing holding me off now is the fact that the packaged blob GRE blob
installer isn't able to unpack its config.ini. I've seen some quirks in the
behavior and tweaked things left and right, but don't have the clarity of mind
to clean this up now.

It's not an ns_temp directory clash. The embedded GRE installer gets its own
directory and unpacks all setup files - except config.ini. I half expect that
there might be some file lock messing me up. Sigh.

Comment 5

[Curt Patrick (gone)]

Actually, the parameter list must be quite a bit longer:

Parameters=-mmi -ma -ms -app mfcembed -app_path [SETUP PATH]\mfcembed.exe

Comment 6

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

Attachment: patch v2

OK, so flipping "Wait=FALSE" to "Wait=TRUE" did it. 

It seems like with "Wait=FALSE" the MFCembed installer instance terminates upon
launching the GRE blob installer. The GRE installer doesn't find another
xpinstall instance and reuses the existing "ns_temp" directory. 

Unfortunately the MFCembed clean-up process seems to be running concurrently to
the GRE uncompressor and gobbles up some of the GRE setup files which are on
its delete list (e.g. config.ini, install.ini, uninstall.ini ect.).

The moral of the story: when embedding xpinstalls we'll have to keep the parent
xpinstall around ("Wait=TRUE") or change the code checked in in bug 167606.

Comment 7

[Curt Patrick (gone)]

Comment on attachment 102621 [details] [diff] [review]
patch v2

I still need to look at the behavior with and without the -ms option, but this
patch is a good place to start testing from.

r= curt

Comment 8

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

cc'ingf leaf for sr=

Comment 9

[Curt Patrick (gone)]

I did get a chance to took at the UI and it looks good the way it is.

Comment 10

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

*** Bug 168361 has been marked as a duplicate of this bug. ***

Comment 11

[Daniel (Leaf) Nunes]

Comment on attachment 102621 [details] [diff] [review]
patch v2

sr=leaf, if dveditz is a driver these days, get a=dveditz before checking in.

Comment 12

[Curt Patrick (gone)]

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?

Comment 13

[timeless]

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

Comment 14

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

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.

Comment 15

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

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.

Comment 16

[Curt Patrick (gone)]

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?

Comment 17

[timeless]

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.

Comment 18

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

timeless- cool! That'll do :-)

Comment 19

[Asa Dotzler [:asa]]

Comment on attachment 102621 [details] [diff] [review]
patch v2

a=asa for checkin to 1.2 (on behalf of drivers).

Comment 20

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

checked in

Comment 21

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

marking fixed, the GRE app path issues moved to a new bug 176116

Comment 22

[Charles Rosendahl]

Verified - all specific bugs will now be filed as such.