Re: Other version information
- From: "mayayana" <mayaXXyana1a@xxxxxxxxxxxxxxxx>
- Date: Thu, 3 Jan 2008 10:26:31 -0500
That link really helps.And I come to know there is no methodsThe download has some explanation in it. I assume
available to get these details like FileSystemObject's
GetFileVersion().The class in the above link is very complex to
understand,Is any other class or methods provide these details ? It
may be more helpful.
you found that. Basically the class reads a PE file's
header to locate the resource table. It then parses
the multi-tiered index of the resource table to locate
the version info. data. The information you want is
standardized. Windows PE files (EXE, DLL, OCX, etc.)
have a very involved standard, part of which specifies
how those files can store icons, strings, etc. as "resources"
that can later be located through the file header. Version
info. is one type of possible PE resource. If you look in a
32-bit EXE you'll usually find somewhere the string
VS_VERSION_INFO. That's Microsoft's characteristically
"poetic" name the the version info. resource. The actual
data follows that, as plain strings delimited by nulls. (Chr(0)).
So the class reads the PE file header, then the resource table,
in order to find the actual location of the version info.
The small function that returns the actual info. can be
edited to return any combination you want. As written it
returns 5 basic values, I think. It's written that way
because in the actual version info. data, each value is
marked by a literal string. like:
*Description*A program that does something**Version*1.2.0.1*
In that sample the *'s stand in for nulls. As you can see, it's
fairly easy to just parse the whole mess as a string.
With the Windows API there are methods to have that
data returned. (GetFileVersionInfo and GetFileVersionInfoSize.)
Even those methods are very complex to use. :)
(As you can see, it's very odd that Microsoft took the
trouble to filter all that data so that they could provide
FSO.GetFileVersion, but then never bothered to finish
the job by returning all version info.)
The class is unavoidably complex in two ways: 1) The
Portable Executable file format is very complex. 2) The
FSO and WSH have no functionality specifically designed
for binary files. Textstream sees a Chr(0) as the end of
a string. So a few workarounds are required.
Another method, which I didn't think of before, if
the Shell.Application GetDetailsOf function. See here:
http://www.microsoft.com/technet/scriptcenter/guide/sas_fil_lunl.mspx
There are also some limitations with that. The Shell.Application
is actually functionality designed for Explorer web view.
Script happens to be able to access it, but it's not
well designed. It relates to actual folder view rather than
file system details. For instance, when you enumerate
files in a folder, what's returned can't be trusted. On
Win98 it won't return system files like .DLL, .DRV, etc. On
WinXP it won't return hidden files, even if those files are
visible due to Folder Options settings, etc. And the Details
seen in Detail View (which is what GetDetailsOf returns) vary
by Windows version. If you're only dealing with XP, and
you don't have hidden files, then GetDetailsOf *might*
be serviceable. But watch out for the quirks. I think the
whole of Shell.Application was never meant to be anymore
than a "hodge-podge" - a thrown-together collection of
code specifically put there to display, and respond to events
in, Explorer windows in "web view".
.
- References:
- Other version information
- From: Saravana
- Re: Other version information
- From: mayayana
- Re: Other version information
- From: Saravana
- Other version information
- Prev by Date: Re: Executing a command with options
- Next by Date: Re: Executing a command with options
- Previous by thread: Re: Other version information
- Next by thread: Re: Other version information
- Index(es):
Relevant Pages
|
