Open Bug 1554450 Opened 7 years ago Updated 3 years ago

7z installer stub (7zSD.sfx) no longer works on XP

Categories

(Firefox :: Installer, defect, P3)

Product:
Firefox
Component:
Installer
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox69 --- fix-optional

People

(Reporter: mark, Unassigned)

References

(Regression)

Details

(Keywords: regression)

It seems that the current 7zstub on the full installer no longer runs on Windows XP.
As far as I understood, the compilation is done with a very old toolchain to provide compatibility with old operating systems, so that the installer may provide NSIS' custom error message that a certain minimum version of the operating system is required.

However, it seems the 7zSD.sfx module now in use (18.05) will no longer work on Windows XP and will load itself into memory but then just sit there and do nothing. No window is spawned, no files are extracted. I've tested this briefly with the FF 67.0 installer after getting reports of the installer based on 7z 18 no longer providing a good experience for those users. Even a generic error from an unsupported subsystem would be better than just hanging in memory ;)

Perhaps it is inherent to Igor's code changes, or perhaps the Mozilla edits need to be looked at for using v18?

Could you find a regression range?

Possibly; I'd have to do this manually by trying to run installers on Win XP. Is there an archive of nightly installers I can butterfly through?

(In reply to Mark Straver from comment #2)

Possibly; I'd have to do this manually by trying to run installers on Win XP. Is there an archive of nightly installers I can butterfly through?

https://ftp.mozilla.org/pub/firefox/nightly/

This definitely wasn't an intentional change; the exact issue you're talking about is what prevented me from landing bug 1522928. But maybe it's actually something else that's causing that.

Priority: -- → P3

Last good version: firefox-60.0a1.en-US.win32.installer.exe 2018-02-14-22-48-14-mozilla-central
First bad version: firefox-60.0a1.en-US.win32.installer.exe 2018-02-15-10-39-33-mozilla-central

LG version uses 7z sfx v4.42, FB version uses 7z sfx 18.1

The culprit seems to be the update of the 7zSD module to v18.

Thanks for tracking that down. The update you're talking about was bug 1436475, so we'll consider that responsible for this regression. Making that change got us a huge performance improvement, so I'm not really willing to roll it back (I can't easily roll it back anyway, because I've also since switched us to using the LZMA SDK for licensing reasons).

The thing is, the unmodified source directly from 7-zip.org and built in Visual C++ 6 using the Windows SDK for XP SP2 gets me exactly the same behavior. I was convinced I had messed up building our binary somehow, but it looks like something else is going on.

Regressed by: 1436475

(In reply to Matt Howell (he/him) [:mhowell] from comment #6)

Making that
change got us a huge performance improvement, so I'm not really willing to
roll it back (I can't easily roll it back anyway, because I've also since
switched us to using the LZMA SDK for licensing reasons).

To be frank, I don't really think anyone minds if extracting an installer takes a little longer, especially if it has (like it does) a progress bar.

The thing is, the unmodified source directly from 7-zip.org and built in
Visual C++ 6 using the Windows SDK for XP SP2 gets me exactly the same
behavior. I was convinced I had messed up building our binary somehow, but
it looks like something else is going on.

It may be something Igor has changed in his extraction code then that is no longer compatible with XP. Not that I particularly blame him for optimizing his code for current-day and non-obsolete operating systems, of course...

(In reply to Mark Straver from comment #7)

To be frank, I don't really think anyone minds if extracting an installer takes a little longer, especially if it has (like it does) a progress bar.

It matters a whole lot more than whether this binary runs on XP or not.

It may be something Igor has changed in his extraction code then that is no longer compatible with XP. Not that I particularly blame him for optimizing his code for current-day and non-obsolete operating systems, of course...

That's possible, but the official 7-zip releases run fine, so I think there's most likely either something we're doing to cause this or at least some way we could work around it. It's not immediately obvious to me what that could be, though.

(In reply to Matt Howell (he/him) [:mhowell] from comment #8)

It may be something Igor has changed in his extraction code then that is no longer compatible with XP. Not that I particularly blame him for optimizing his code for current-day and non-obsolete operating systems, of course...

That's possible, but the official 7-zip releases run fine, so I think
there's most likely either something we're doing to cause this or at least
some way we could work around it. It's not immediately obvious to me what
that could be, though.

Hmm but you yourself already ruled out the Mozilla-specific patches:

The thing is, the unmodified source directly from 7-zip.org and built in Visual C++ 6
using the Windows SDK for XP SP2 gets me exactly the same behavior.

So the question is then: Why do Igor's sfx binaries run properly, while the (assumed built the same way) sfx you built does not?

(In reply to Mark Straver from comment #9)

Hmm but you yourself already ruled out the Mozilla-specific patches:

Right.

So the question is then: Why do Igor's sfx binaries run properly, while the (assumed built the same way) sfx you built does not?

Exactly. I have no idea. I'd like to investigate at some point, but I have higher priorities right now. I would certainly not turn down any assistance.

I've done some more testing, and I'm afraid your previous assessment was wrong. Plain SFX modules (without the Mozilla modifications) from the LZMA SDK source (I tried both 19.00 first and then to be sure also 18.05) built in the same build setup as the Firefox 7zSD version that shows this issue DO run properly on Windows XP. So it must be something specifically with the Mozilla patch that breaks it.

You're right, sorry for the red herring. I did have a freshly downloaded source tree, but I must have been running the binary out of the wrong path.

I've isolated the part of our patch that it's unhappy about. It's the project file change in bug 1361326, where I added the /delayload switches (the code change that's also in there makes no difference either way). Specifically, the delayed load of shell32.dll is the one triggering the hang. I'm definitely not about to revert a security fix over this, so more investigation is still needed of what changed that would have caused this to become a problem and what we might be able to do about it.

As a solution, isn't it possible to simply throw up an alert very early in the module (before trying to extract anything) that does an OS check and aborts, instead of relying on successful extraction and then NSIS to inform the user?

We already have that check before we try to extract any files. The problem is that the binary isn't even getting far enough to run that code.

How has Igor solved the dll hijacking problem? Can that be used, instead?

Has Regression Range: --- → yes
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.