We can not set the InstallDefalults flag entirely in the
bootstrapmain.pas. Because we do not yet have the Msi Version info.
So we need to do that in RunTools.pas. However, we need to know
if this is continuing set up after a reboot, as we don't look at
previous version info if it is, as it would have been removed.
This is why the ContinueSetup flag has been made available to Runtools
The install defaults flag will set the registry values
to their default values.
This flag can also be used by the installer itself when it needs to
do a restart to continue installing. It can check to see if this is
a fresh install or an upgrade and set the flag accordingly.
There was a time, pre version 11 when the Product version GUID was
the same between versions. That is no longer the case.
Now we only set defaults if no previous installed version exists.
Fixes#6221.
If Keyman is being installed under the SYSTEM profile, e.g. when using
tools such as SCCM or Intune, then the installer runs with a redirected
folder for %LocalAppData%, under C:\Windows\SysWow64\config, but is
given the name C:\Windows\System32\config\....
Keyman Setup then creates %LocalAppData%\Keyman\Diag, which it thinks is
in C:\Windows\System32\config\... But in reality it is in SysWow64\...
Keyman Setup passes a file under this folder to Windows Installer,
running as 64 bit, which immediately falls over because the path does
not exist to it, in the real System32\config folder.
This patch disables redirection temporarily just to create the folder
under both 32 and 64 bit versions of the profile. It has no effect on
normal user accounts (apart from verifying that the folder is present
twice rather than once).
Fixes#4886.
This patch includes 5 separate fixes for the various scenarios we
encountered during package installation.
1. RunTools.pas: don't attempt to install TIPs if package is not also
being installed.
2. Keyman.Setup.System.OnlineResourceCheck.pas, OnlineUpdateCheck.pas:
handle online update check for packages with spaces or periods in the
id (legacy packages only).
3. Keyman.Setup.System.InstallInfo.pas: Handle browsers renaming
downloaded files with `(n)` and `[n]` patterns as well as the current
` (n)` pattern.
4. Keyman.Setup.System.InstallInfo.pas: Handle browsers renaming
downloaded files with `_n` pattern. See code comments for details.
5. Keyman.Configuration.System.TIPMaintenance.pas: Avoid crashing if
`kmshell -install-tips-for-packages` is passed an invalid package
name.
The crash is actually fixed in point 5 above, but the root causes are
addressed in the other points.
Fixes#4520.
Start Keyman after Setup finishes only if Keyman is not already running.
The pattern in this code change is found in a few places. It would be
nice to centralise that in a unit somewhere but I don't want to do
that much refactoring at this point in beta.
Fixes#4467.
Background: in some scenarios, e.g. files in use, Setup must restart
before it completes. This is particularly the case if kmcomapi.dll is
locked and Windows will move the new version into place after a restart.
In this scenario, we would end up calling the old version of
kmcomapi.dll to install keyboards, etc, which is definitely not
desirable.
Problem: Setup was not saving complete state before the restart, so when
it resumed post-restart, would get a blank slate to work from, losing
command-line options passed in and any choices that the end user may
have made during the installation.
Fix: This PR adds serialization of the `TInstallInfo` state data, so
that the install state can be saved to disk before restart, and reloaded
after the restart. This also means that the `-c` parameter now takes a
filename, being the temporary state JSON file, and when in
"ContinueSetup" mode, no longer needs to perform all the checks it did
previously, making the second half of Setup somewhat faster.
Testing: Added a unit test for the serialization of `TInstallInfo`, and
have tested on a VM in various scenarios without problems.
This fix is somewhat broader than I really like to make while in Beta,
but I don't think there was a viable alternative.
Fixes#4003.
This addresses the majority of locations where we use the name "Keyman
Desktop" in code. There will be some filenames and paths that do not
change at this point -- particularly at a source level. For now, the
focus is on the user interface changes.
While making these changes, I also made the VERSION and MANIFEST
resources more consistent.
Where more than one source of a file is available, e.g. a local
keymandesktop.msi which is older than the current published version
online, then Setup will choose the newer, online version by default,
but allows the user to change the install source in the Options dialog
to have an offline setup if they prefer.
This means that the 'best' location is now chosen at startup, and then
the user can override that.
Relates to #3689.
Fixes#3690.
This applies an 'Installing Keyman' label during the install. While
Windows Installer does supply some status messages, at present we are
not using those. Also fixed a missing i18n string.
This upgrades a 11.0-13.0 install to the 14.0 model for registered TIPs.
It does not yet deal with transient TIPs or disabled keyboards (these
will come in a separate PR). There is also more tidy up coming in a
future PR for language names.
This splits the registration and installation of TIPs according to the
elevation context during the installation process, so that the current
user gets the correct configuration, regardless of who the elevated user
is.
This starts the refactoring of Keyman Setup for Windows
for a more online-first bootstrap approach for bundling.
For users who are offline, the traditional bundled approach
works, as does throwing package files into the same folder
as setup.exe. This makes the whole installer much simpler
to deploy and test.
At this stage, there are a lot of rough edges, so need to
refine these, including setup strings, language choices,
and error and logging management.
