...now again with signature disabled as this seems to break the size-limit of
the mailing-list...
Even if the other solution with the named object sounds like the most elegant
version, I'd
would probably go with the simplest (k.i.s.s), as the room for breakage is the
least
(and not being totally unselfish, I see hope that this might still slip into
the 3.8 release,
whereas the other one would probably need more coding & testing ;-)
Concerning the run-key-approach: so that would mean in case the local system
has on
OS lower than Vista, the Run-key is used instead of the RunOnce - correct?
_____
Von: Rob Mensching [mailto:r...@robmensching.com]
Gesendet: Freitag, 8. November 2013 16:13
An: WiX toolset developer mailing list
Betreff: Re: [WiX-devs] Issue & possible solution: Burn Startup-Screen is shown
twice (on Windows XP) if bootstrapper contains driver-installation
What if on XP Burn writes to the Run key instead? That's actually what we did
in for all OSes in the early days of Burn. We had to move to the RunOnce key to
ensure on restart the Bundle launched elevated and the user would not be
prompted for elevation post-restart. Fortunately, on XP we don't have to worry
about elevation.
This could also be the most straight forward fix if it works. I'm hoping the
"runonce.exe" just runs the runonce key. <smile/>
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Friday, November 8, 2013 6:41 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Issue & possible solution: Burn Startup-Screen is shown
twice (on Windows XP) if bootstrapper contains driver-installation
That sounds workable, If the engine detects a restart it would need to re-write
the run-once key.
Hmm,
An oversimplification would be:
Create a named event/mutex/semaphore (pick your poison) using either
per-user or per-machine namespace depending on if this is a per-user or
per-machine install.
Store this sync object name in the session state so on restart the BA can
look for it.
Write the run once key
<Let the engine do all the other fun stuff it is doing>
Clear the sync object name from the session
Release the sync object and exit
I'd strongly advise against adding any more options to the command line, as
we have had issues already today w/ the command line and options exceeding
MAX_PATH.
From: Tobias Erichsen [mailto:i...@tobias-erichsen.de]
Sent: Friday, November 08, 2013 8:22 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Issue & possible solution: Burn Startup-Screen is
shown twice (on Windows XP) if bootstrapper contains driver-installation
The PID will always be different, since it is a new process created by the
service.exe system-component.
I want to make sure that if it is executed, a prior reboot indeed occured -
otherwise the process will
shut down immediately without doing anything (and not even showing a
user-interface)
_____
Von: John Cooper [jocoo...@jackhenry.com<mailto:jocoo...@jackhenry.com>]
Gesendet: Freitag, 8. November 2013 15:07
Bis: WiX toolset developer mailing list
Betreff: Re: [WiX-devs] Issue & possible solution: Burn Startup-Screen is
shown twice (on Windows XP) if bootstrapper contains driver-installation
Have you considered a UNIX-like approach like passing the PID? Burn could
easily check it's PID against the passed value to see if it is already running.
--
John Merryweather Cooper
Build & Install Engineer -- ESA
Jack Henry & Associates, Inc.(r)
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com<mailto:jocoo...@jackhenry.com>
www.jackhenry.com<http://www.jackhenry.com>
From: Tobias Erichsen [mailto:i...@tobias-erichsen.de]
Sent: Friday, November 8, 2013 3:18 AM
To: wix-devs@lists.sourceforge.net<mailto:wix-devs@lists.sourceforge.net>
Subject: [WiX-devs] Issue & possible solution: Burn Startup-Screen is shown
twice (on Windows XP) if bootstrapper contains driver-installation
Problem:
========
When burn is used to install one or more MSI-packages (very probably also
exe-packages) on Windows XP
and one of the packages contains a driver install, the burn-bootstrapper is
started a second time
during the installation-chain, showing the startup-screen once more
erroneously.
The install itself is going through successfully and the final "Success"
screen is shown at the end.
This is very annoying, as the second startup-screen will confuse customers
to think that the
installation did not go through correctly.
This behavior does not show up on Windows 7 or 8.
Analysis:
=========
During analysis using the Process-Monitor-Tool I discovered that the second
(erroneously shown)
burn startup-screen was shown by the bootstrapper that is instantiated by
the runonce executable
(complete process-chain: services.exe -> msiexec.exe -> msiexec.exe ->
runonce.exe -> burn_bootstrapper.exe)
Being instantiated from runonce.exe and also the specific commandline
provided to the bootstrapper
(/burn.runonce) revealed that the bootstrapper was re-run due to it being
written to the RunOnce
registry-key.
Burn writes this RunOnce registry-key to restart itself in case of reboot
during the package-installation-
chain.
Unfortunately it seems like this RunOnce feature is executed prematurely.
There are two links to this topic that someone mentioned on the wix-users
mailing-list:
http://blogs.msdn.com/b/junfeng/archive/2006/09/19/761765.aspx
http://support.microsoft.com/kb/281820
It seems like a driver-installation might fire the RunOnce-registry-keys due
to driver-infs having
the feature to also contain RunOnce options that the driver-install-creator
might want to have
executed post inf-installation.
Obviously this interferes with the RunOnce usage of burn.
There are two sub-problems:
Part 1:
=======
The errouneous display of a second installer startup-screen.
Part 2:
=======
The intended use for RunOnce in burn is foiled due to the Registry-Key being
deleted by the
premature firing of the RunOnce condition.
Solution Part 1
===============
Is possibly fixed very easy. The commandline written into the RunOnce-key
must be expanded to
contain some kind of information for the new (RunOnce-initated) burn-process
to find out whether it
is still running in the same boot-session, or an intermediate boot has
occurred.
If it is still the same session, the burn-process should stop immediately,
showing no user-interface.
If it detects a reboot in between it will proceed like intended.
Two methods for detection come to mind:
a.) add the current-time (in UTC) to the command-line.
This way the RunOnce-initiated detection can use its current time & the time
since the last boot to
find out if a reboot has taken place in between.
b.) In case some unique ID (GUID?) exists that Windows sets to a new value
on each reboot, this might
be put on the commandline & checked by the RunOnce-initiated burn-instance.
Any pointers to such an
id would be highly welcome...
Solution Part 2
===============
I'm not 100% sure about the total burn-architecture, so my proposal might
interfere with other features...
Instead of calling the UpdateResumeMode function (in registration.cpp) once
at the start of the install,
it should be called once before each package in a chain.
This way it gets refreshed in case one of the packages cause the RunOnce
action to be fired prematurely.
I'd be happy to get feedback on my ideas...
Best regards,
Tobias
NOTICE: This electronic mail message and any files transmitted with it are
intended
exclusively for the individual or entity to which it is addressed. The
message,
together with any attachment, may contain confidential and/or privileged
information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
