Sumatrapdf: Notify of 32 vs 64-bit mismatch in the installer

[kjk]

If there's a 32-bit vs 64-bit mismatch between the installer and the OS, detect that in the installer and notify the user somehow.

[SumatraPeter]

The message can also make note of the fact that such a mismatch will prevent installation of the IFilter and previewer (so people who have seen screenshots etc. of the installer don't wonder why those options are missing for them).

[SumatraPeter]

Also, if the 32-bit version is installed and the 64-bit installer is run it updates in the existing location itself, right? I wonder if it might not make more sense for the installer in that case to wipe Program Files (x86)\SumatraPDF and install in the proper Program Files\SumatraPDF location instead?

[GitHubRulesOK]

@SumatraPeter I agree the old paths may have affected some of my odd installation behaviours, however there are some users like myself who would not want an enforced wiping of the other location.
It has sometimes caused problems that the opposite bitness WILL erase the oposing RAR.dll location

My personal preference is (as suggested by others) to not have the rar.dll remote but keep it together in the same directory with the exe so 32bit.dll stays in Program Files (x86)\SumatraPDF whilst 64bit stays in Program Files\SumatraPDF I can then use the two as required
The key issue is the related installers should initially default to their correct path (and respective uninstaller should only remove one path in full)

[SumatraPeter]

however there are some users like myself who would not want an enforced wiping of the other location

I think you misunderstood what I was suggesting. It is my understanding that if you already have the 32-bit version installed in Program Files (x86)\SumatraPDF and you run the installer for a newer 64-bit version, it updates the program in the existing location. However this leads to the anomalous situation where the 64-bit version is now installed in Program Files (x86)\SumatraPDF.

So what I was recommending was that in such cases the installer should silently and seamlessly install in the proper Program Files\SumatraPDF location and wipe Program Files (x86)\SumatraPDF once it's done. The user will be none the wiser and there will be no mix-up of bitness and installation folders.

Keeping Program Files (x86)\SumatraPDF\UnRAR.dll around in such cases like you are suggesting will be pointless anyway given that the 64-bit Sumatra installed in the proper Program Files\SumatraPDF location will need the matching UnRAR64.dll.

My personal preference is (as suggested by others) to not have the rar.dll remote but keep it together in the same directory with the exe

That's what we do now, i.e. manually download and extract the UnRAR/UnRAR64.dll from RAR's site, then move to the installation folder. However this is extremely user-unfriendly and kjk of course plans to automate it. In that case it would make more sense for the program to download and extract the appropriate 32/64-bit DLL to %AppData%\SumatraPDF. With UAC being introduced from Vista onwards that's the recommended behavior for non-admin programs anyway given the default permissions for system folders (any attempts to write to Program Files, Windows etc. will make folder virtualization kick in).

[GitHubRulesOK]

@SumatraPeter I am not trying to argue a behaviour for keeping both installations on one machine. I normally run both portable and do see the merit of only having 64 bit on an x64 installation. However I am echoing comments in https://github.com/sumatrapdfreader/sumatrapdf/issues/1116 and my own observations that when both bitness are (for whatever reason) installed on the same machine then the 64bit install will replace the 32bit.dll thus fouling use of the 32bit installation.

[SumatraPeter]

First of all #1116 is about the portable versions, and that is indeed a bug that needs to be fixed as I've myself written more than once. However that has _nothing_ to do with _this_ issue!

As per my suggestion _here_, the 64-bit installer will install in Program Files\SumatraPDF and wipe the 32-bit version (if installed obviously) from Program Files (x86)\SumatraPDF. Naturally any 32-bit UnRAR.dll you've manually copied to that folder will be gone as well, but as I've stated above you'll need to copy UnRAR64.dll afresh _in any case_ for the 64-bit version you just installed. Moreover in future (hopefully) the appropriate DLL will be downloaded by Sumatra automatically into %AppData%\SumatraPDF, so there goes your headache of downloading and keeping track of which bitness DLL you need.

So what's getting 'fouled'? I see no reason for anyone to have both 32 and 64-bit versions installed. Sure, they can have one installed and perhaps the other downloaded as a portable version, but _installing_ both on a 64-bit system makes no sense.

[mirh]

Why would you care for "mismatch"?

[SumatraPeter]

@mirh: See my comment above. Users running the 32-bit installer by mistake on 64-bit Windows will not be shown the options to install the desktop search and Explorer preview components because of bitness mismatch.

[SumatraPeter]

@kjk: All this discussion makes me think of an alternative solution that many programs follow nowadays - a combined 32 and 64-bit installer. If the common files are deduplicated and the rest compressed, the overall combined installer size shouldn't be all that big (heck, even adding the current sizes makes it only 38MB!).

This will solve all user headaches in that the installer will automatically install the appropriate bitness version and perform clean-up as required. What do you think?

[kjk]

I don't think people would like it if installer size doubled. I won't be happy when my bandwidth bill doubles.

[GitHubRulesOK]

@kjk perhaps you could explain on download page the merits of 64bit installer over 32bit and offer that first as its now likely the more useful except for legacy outlook users

[mirh]

not be shown the options to install the desktop search and explorer preview

Oh right, fair point.

If the common files are deduplicated and the rest compressed, the overall combined installer size shouldn't be all that big

Ehrm.. Are there even? Dlls and executables must all be of the same bitness.

[SumatraPeter]

I don't think people would like it if installer size doubled. I won't be happy when my bandwidth bill doubles.

@kjk: I doubt an _occasional_ download of 38MB (or quite likely less) will affect users so much compared to one of 19MB or so. Or is file size everything? If so then better to listen to that guy who was complaining yesterday on the forum and rollback the update to the latest MuPDF, because that has made everyone's bandwidth bill more than 4-5x more than what it was earlier:

32-bit installer went from 4.63 MB (3.1.2) to 19.0 MB (prerelease 11305) = ~4.10 times increase.
64-bit installer went from 4.96 MB (3.1.2) to 19.4 MB (prerelease 11305) = ~3.91 times increase.

32-bit portable went from 6.18 MB (3.1.2) to 32.2 MB (prerelease 11305) = ~5.21 times increase.
64-bit portable went from 6.91 MB (3.1.2) to 33.3 MB (prerelease 11305) = ~4.82 times increase.

When we're already seeing such huge file size jumps, what's the big deal with a ~38 MB combined installer (not much different from either current portable version in size) anyway? Remember that the unauthorized Windows Store version provides the exact same advantage I'm suggesting here, in that users simply click the install button and the appropriate bitness version is installed matching their OS. No notifications required, no muss, no fuss.

---

Ehrm.. Are there even? Dlls and executables must all be of the same bitness.

@mirh: There are bitness-agnostic files such as fonts etc. I think. But even if there are no common files, simply adding up the current sizes still results only in a ~38MB installer, which I think is hardly such a big issue in this day and age (especially since new versions are released once in a blue moon). The advantages far outweigh the size increase IMO, but if kjk doesn't want to do it that's up to him.

[GitHubRulesOK]

@SumatraPeter I am the last house on a piece of copper string so actually it can have an effect especially when Microsoft enforce updates (but do agree with you 40mb is no great shakes)

I Think the point @kjk was trying to make is HE has to pay double for the Bandwidth as a result of unneeded downloads

[SumatraPeter]

I Think the point @kjk was trying to make is HE has to pay double for the Bandwidth as a result of unneeded downloads

That is indeed a valid point I didn't consider. Well, ultimately it's his decision anyway. If he's fine dealing with all this bitness nonsense till 32-bit goes the way of the dodo (then start again when 128-bit comes along! 🙂), who am I to complain? I'm not affected so ultimately makes zero difference to me.

Perhaps some day there'll be an official Store version that we can steer naive users to. It can even be a paid version to support development with the non-Store versions continuing to be free, which is a model that Paint.NET is following quite successfully.