Vista - Interesting FSO bug

This is an upshot of the discussion last week
about getting browser versions. In checking
the file version of firefox.exe I wondered why
anyone who had accessed a file through FSO
would then go to all the trouble of switching to
WMI to get the file's version, when FSO has
the GetFileVersion method. (One of the solutions
offered worked that way, using both FSO and WMI.)

Just to double-check, I ran FSO.GetFileVersion on
firefox.exe. I have FF 1.5 installed. This was the
result:

fso 1.8.20070.50813
wmi 1.8.0.12: 2007050813

The Firefox version number is probably not a "legal"
version in Windows. I've never seen a colon before
in a file version number. The Mozilla people apparently
just decided to make up their own standard.

On the other hand, file version comes from the
VS_VERSION_INFO resource in a PE file. The structure
of that is defined. All of VS_VERSION_INFO is in string
form. The version number is not stored as numbers. It's
stored as a unicode string, periods and all, like:
1-.-8-.-0-.-1-2- etc. (where - is a null)

Looking at firefox.exe in a hex editor I was able to
cofirm that WMI had the correct version string. So what
is FSO returning? It appears that this is some kind of
parsing bug in the FSO/scrrun.dll. FSO.GetFileVersion
seems to be applying some kind of complex (and
uncalled-for) formula to the version string.... a formula
that can't handle Mozilla's unorthodox version string
formatting.

The long and the short of it is that FSO.GetFileVersion
cannot be depended upon to return accurate data.

Just to clarify: Firefox not only has an unusual
file version number format. It also switches
file version and product version. The file version
reported is actually the gecko version, while
Firefox's product version is the installed Firefox
version number. (That's why I showed file version
1.8 for an installed FF version of 1.5.)

So firefox's file version number is not of much use
in any case. But that's a side issue. WMI, Windows,
and the version info. of the firefox.exe resource
table all agree on one file version number, while FSO
mangles that number somewhere along the line.

mayayana wrote:
It is an interesting topic.

If I click Help/About in my FireFox I see

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.11)
Gecko/2009060215 Firefox/3.0.11


When I run my WMI script I get Version: 1.9.0.3439

This would all be so much easier if the Mozilla folks would enable
FireFox for VBScript.
--

David Kerber wrote:
I am referring to the need to be able to script its use, such as can be
done with IE like:

Set IE = CreateObject("InternetExplorer.Application")
IE.Visible = False
IE.Navigate("http://companyweb")
IE.Visible = True



--

There is actually an ActiveX control.
http://www.iol.ie/~locka/mozilla/control.htm

I don't know if it's any good. I downloaded it once
and it basically installed an entire copy of Firefox
as part of the control. So it wouldn't work to ship it
with software.

The FF control is equivalent to a WebBrowser
control -- a browser instance that needs to be sited
in the window of some other process. I would think
that whatever COM interfaces were created for that
control might be adapted to create an automation
object EXE.

I really don't see what advantage that would
provide, though. The IE automation object, especially
with HTAs, is remarkably functional. I don't see any
need to have a FF automation object. Actually I don't
even regard them as the same kind of software. I see
IE as a scriptable program for creating scripted GUIs
on Windows, and Firefox is a web browser for going
online. Each seems ill-suited for the job that the
other does well.

mayayana wrote:
Biggest reason I would like to see it included in a regular FF download
is that there are a lot of problems right now with IE8. I prefer to
use IE, however on my WIndows 7 x64 installation I've had to switch my
default browser to FF because IE8 is so unpredictable. One minute it
works great and the next it can take 2 minutes to navigate to a web
page. Using FF at the same moment that IE is delayed opens right up.

I trust MS will fix this with SP1 for IE8 but I really can't wait for
that.

--