Windows: Update version number in Add/Remove Programs on update

[dstillman]

https://forums.zotero.org/discussion/79866/zotero-updater-not-changing-version-number-in-add-or-remove-programs

(Firefox now does this. We should see what they're doing to change a key in the registry.)

[dstillman]

It looks like we'd need to update DisplayVersion in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Zotero 5.0.96.2 (x86 en-US) (as long as we're a 32-bit app).

Mozilla seems to do this with the maintenance service, which doesn't help us:

https://searchfox.org/mozilla-central/rev/ac7a567f036e1954542763f4722fbfce041fb752/toolkit/components/maintenanceservice/serviceinstall.cpp#460

https://searchfox.org/mozilla-central/rev/ac7a567f036e1954542763f4722fbfce041fb752/toolkit/components/maintenanceservice/serviceinstall.cpp#31-43

But we could theoretically do this with nsIWindowsRegKey without messing with our updater:

http://udn.realityripple.com/docs/Mozilla/Tech/XPCOM/Accessing_the_Windows_Registry_Using_XPCOm

I guess we could do it on startup when the current DisplayVersion didn't match the current app version. (If so, this would belong in zotero/zotero.)

[adomasven]

But we could theoretically do this with nsIWindowsRegKey without messing with our updater:

We have some example code using this https://github.com/zotero/zotero-word-for-windows-integration/blob/master/resource/installer.jsm#L75

[dpprdan]

I guess we could do it on startup

Just a minor point, but is there an easy way to make the update happen directly after installation? If the auto-update happens without a restart, the installed and reported-by-ARP versions are out of sync until the next restart.

[dstillman]

Updates happen on restart, so the new version always starts up immediately.

[dstillman]

https://forums.zotero.org/discussion/116331/zotero-updater-should-update-version-displayed-in-windows-control-panel

[dstillman]

Except we can't actually do this in the app itself, because writing to HKLM requires administrative privileges…

Otherwise code like this would work:

var version = Zotero.version;
var arch = Zotero.arch;
if (arch == 'aarch64') {
	arch = 'ARM64';
}
else if (arch == 'x86_64') {
	arch = 'x64';
}
else if (arch == 'i386') {
	arch = 'x86';
}
var versionString = `${version} (${arch})`;

var appDir = FileUtils.getDir('GreBinD', []).path;
var wrk = Components.classes["@mozilla.org/windows-registry-key;1"]
	.createInstance(Components.interfaces.nsIWindowsRegKey);
wrk.open(
	Components.interfaces.nsIWindowsRegKey.ROOT_KEY_LOCAL_MACHINE,
		"Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall",
		Components.interfaces.nsIWindowsRegKey.ACCESS_READ
);
try {
	let i = wrk.childCount - 1;
	for (let i = wrk.childCount - 1; i >= 0; i--) {
		let name = wrk.getChildName(i);
		if (!name.startsWith(Zotero.appName)) continue;
		let child = wrk.openChild(
			name,
			Components.interfaces.nsIWindowsRegKey.ACCESS_READ
				| Components.interfaces.nsIWindowsRegKey.ACCESS_WRITE
		);
		try {
			let installLocation = child.readStringValue('InstallLocation');
			if (installLocation == appDir) {
				child.writeStringValue('DisplayVersion', versionString);
			}
		}
		finally {
			child.close();
		}
	}
}
finally {
	wrk.close();
}

But it just throws NS_ERROR_FAILURE if ACCESS_WRITE is used.

So I think we'd have to patch the updater itself to update the registry key, borrowing code from the Mozilla Maintenance Service.

[dstillman]

Actually, the linked code above is just for the Maintenance Service to update its own entry. For Firefox itself it's handled via the uninstaller's helper.exe with a /PostUpdate switch. I'll look into why that's not working for us.