View Single Post
  #19  
Old December 4th 17, 09:56 AM posted to microsoft.public.windowsxp.general
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Crashes with Firefox Quantum

Bill in Co wrote:
Bill in Co wrote:
J. P. Gilliver (John) wrote:
In message , Bill in Co
writes:
J. P. Gilliver (John) wrote:
In message , Bill in Co
writes:
J. P. Gilliver (John) wrote:
In message ,
Andy writes:
Is anyone else getting frequent crashes with Firefox Quantum ?

I didn't think Quantum (alias Firefox 57, I think) runs under XP; I
thought 52 was the last that would.
Yup, it says FF 52 is the last version for Windows XP, so am I missing
something? :-) Speaking of which, the older versions still work
fine, at least over here. I'm hoping we don't get to a point where
that doesn't happen anymore, but I may be too optimistic.


(I was really wondering why Andy was asking here - as have others.) If
you've got an old version that is working, it will continue to do so;
the only reason for that to appear not to be the case will be if web
page designers start to include features that only work with the newer
versions. So far, most companies that do this, I've found an
alternative, so all they've done is lose my custom; however, there may
come a time when all the alternatives are using the new "feature" as
well.
OR are just compiled with a newer compiler that uses some revised DLLs
that are not compatible with the Windows XP OS. IOW, it's not just the
added features of the browser, but the actual code still being
compatible with the
The actual code of what? If you mean the browser, then up to 52 it _was_
compiled (so I understand; I'm still on 26) and runs under XP. And will
continue to do so, for ever. The only thing that will make that appear
not to work will be if web page creators use features not supported in
52, rather than not supported in XP - i. e. it's the version of browser
that's the limiting factor, not XP. Of course, in practice the effect is
similar, unless those features _are_ supported by some other browser
that runs under XP.

Windows XP OS as I understand it. You can see that happening when you
try to install some other newer programs, and you get those cryptic DLL
error messages, and it won't install..

I don't _think_ web pages will call DLLs.

The problem is waaay before that. If you try to install some newer
programs (or newer versions of some older programs) on a Windows XP
system (I should have said System, as that also includes the older Visual
C stuff and whatnot on that older system), it will often fail in one of
three ways: 1) the installer refuses to install it, or 2) the installer
tries to install it and fails, and gives some cryptic DLL error message
about some missing DLL parameters (due to a newer version DLL supporting
them but not the older version), or 3) it can't find some DLL file(s) on
your system.


An addendum and a question for Paul (or someone else who might know):

What I don't understand is whether or not these DLL incompatibility issues
arise from the older Visual Basic or C libraries on a Windows XP system, OR
from some newer DLLs added by the newer program version itself, OR from the
(older) DLLs found on a Windows XP system, at large. Or maybe I'm missing
something here.


EXEs can have a DLL list. And DLLs can have a DLL list.
Once everything is loaded, every subroutine call has an address,
even if the address has to take into account ASLR. The loader
takes care of the details of linking things together. It
cannot link things together, that it cannot "see" and load.

I can upload Firefox 52 EXE and collect the Imports list.
And do the same for 57. The EXE file is a "thin" file that
doesn't do much. The "meat" is in XUL.dll. So if you don't
have a copy of DependencyWalker, you can use Virustotal
as a very crude analysis tool.

Firefox 52

https://www.virustotal.com/#/file/0e...7d41cb/details

Imports:

ADVAPI32.dll
KERNEL32.dll
MSVCP140.dll
VCRUNTIME140.dll
api-ms-win-crt-environment-l1-1-0.dll \
api-ms-win-crt-heap-l1-1-0.dll \
api-ms-win-crt-locale-l1-1-0.dll \
api-ms-win-crt-math-l1-1-0.dll \___ Microsoft also has
api-ms-win-crt-runtime-l1-1-0.dll / pushed these out hard,
api-ms-win-crt-stdio-l1-1-0.dll / via security updates,
api-ms-win-crt-string-l1-1-0.dll / in an effort to support
mozglue.dll some kinda newer stuff.

Firefox 57 (basically, the same, as the EXE "doesn't do anything")

Imports

ADVAPI32.dll
KERNEL32.dll
MSVCP140.dll
VCRUNTIME140.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
mozglue.dll

When I run the XUL.dll files (~50MB size), they
have a few different dependencies. The 57 one is
calling dwmapi.dll and I don't think the Display
Manager goes by that name on Windows XP. There are
some I don't recognize, and would have to start searching
some C: partitions, to find and get a name from them.


Firefox 52 XUL.dll Firefox 57 XUL.dll

Imports Imports

ADVAPI32.dll =
AVRT.dll
CRYPT32.dll =
GDI32.dll =
HID.DLL
IMM32.dll =
IPHLPAPI.DLL =
KERNEL32.dll =
MSIMG32.dll =
MSVCP140.dll =
OLEAUT32.dll =
RPCRT4.dll =
SETUPAPI.dll =
SHELL32.dll =
SHLWAPI.dll =
USER32.dll =
USP10.dll =
UxTheme.dll =
VCRUNTIME140.dll =
VERSION.dll =
WINMM.dll =
WINTRUST.dll =
WS2_32.dll =
WSOCK32.dll =
WTSAPI32.dll =
api-ms-win-crt-convert-l1-1-0.dll =
api-ms-win-crt-environment-l1-1-0.dll =
api-ms-win-crt-filesystem-l1-1-0.dll =
api-ms-win-crt-locale-l1-1-0.dll =
api-ms-win-crt-math-l1-1-0.dll =
api-ms-win-crt-runtime-l1-1-0.dll =
api-ms-win-crt-stdio-l1-1-0.dll =
api-ms-win-crt-string-l1-1-0.dll =
api-ms-win-crt-time-l1-1-0.dll =
api-ms-win-crt-utility-l1-1-0.dll =
dwmapi.dll (W8/W10?)
lgpllibs.dll =
mozglue.dll =
nss3.dll =
ole32.dll =
pdh.dll --- not in 57 (windows performance
data helper, no idea)

This is one of the reasons DependencyWalker output is so
complicated looking, because the imports of every DLL
in the "tree" shows up (recursive analysis). Including
bogus references to some sort of java DLL that hasn't
existed since WinXP SP1 (not available on SP1a, removed by
court decision in Sun vs Microsoft legal case over msjava).

Usually, an analysis without boring down too many
layers, can spot dependencies that an old
OS might not support. And if you hard-wire
something like this into your executable,
it helps work as a booby-trap (if I move my
Firefox 57 folder to my WinXP machine).

But kernel calls work just as well. Both the EXEs
and the DLLs above reference kernel32 and you could pick
a call that's only supported in Vista+ for example,
to prevent WinXP from loading completely.

And that doesn't even include the marking of executables
with some sort of "runs in particular OS version xxx", like
how Solitaire was marked. Microsoft tends to do that to
their own software products. I can't run VPC2007
on Windows 10, even though it would probably
execute given a chance.

Paul
Ads