filever?

Hi All,

Windows provides a utility called filever.exe which will
tell you the revision of an exe file. (You can also see this
through the gui with properties).

I would like to write my own Perl module to return the .exe's
version. Does anyone know where the version information is
stored in an .exe file? (I bet Paul does not even have to
look this one up.)

Many thanks,
-T

T wrote:
Hi All,

Windows provides a utility called filever.exe which will
tell you the revision of an exe file. (You can also see this
through the gui with properties).

I would like to write my own Perl module to return the .exe's
version. Does anyone know where the version information is
stored in an .exe file? (I bet Paul does not even have to
look this one up.)

Many thanks,
-T

Why not find a representative sample of files first,
and try the techniques here ?

https://stackoverflow.com/questions/...-in-powershell

Then you can go off and craft a Perl module to do the same thing.

And when a file doesn't have a version, your Perl code
shouldn't return a version either. Remember that Microsoft
was never that "hungry for version control now". At one
time, patching articles referred to file sizes, as the
identifier of choice. "Replace the 123 byte file with
the 125 byte file" Yuck.

Whereas more modern OS partition content, should have
more metadata.

Mayayana probably has more experience with this than
I do. I haven't had a reason to ferret out version
info for some time.

The unthinkable is also possible.

https://docs.microsoft.com/en-us/pow...w=powershell-6

The only general comment I'd have about that idea,
is that you'd expect some forked commandlet to be slow,
as there'd be some sort of giant environment to fork.
I wouldn't expect that to be able to examine 100 files
per second. Whereas your Perl idea might.

Paul

On 1/29/19 10:38 PM, Paul wrote:
T wrote:
Hi All,

Windows provides a utility called filever.exe which will
tell you the revision of an exe file.Â* (You can also see this
through the gui with properties).

I would like to write my own Perl module to return the .exe's
version.Â* Does anyone know where the version information is
stored in an .exe file?Â* (I bet Paul does not even have to
look this one up.)

Many thanks,
-T

Why not find a representative sample of files first,
and try the techniques here ?

https://stackoverflow.com/questions/...-in-powershell

Then you can go off and craft a Perl module to do the same thing.

And when a file doesn't have a version, your Perl code
shouldn't return a version either. Remember that Microsoft
was never that "hungry for version control now". At one
time, patching articles referred to file sizes, as the
identifier of choice. "Replace the 123 byte file with
the 125 byte file" Yuck.

Whereas more modern OS partition content, should have
more metadata.

Mayayana probably has more experience with this than
I do. I haven't had a reason to ferret out version
info for some time.

The unthinkable is also possible.

https://docs.microsoft.com/en-us/pow...w=powershell-6


The only general comment I'd have about that idea,
is that you'd expect some forked commandlet to be slow,
as there'd be some sort of giant environment to fork.
I wouldn't expect that to be able to examine 100 files
per second. Whereas your Perl idea might.

Â*Â* Paul



Hi Paul,

I was thinking of running an exe through hexedit, but
I could be looking at thousands of line. EEEEE.

Also, the perl module will be running under Linux.

-T

On 1/29/19 10:47 PM, T wrote:
On 1/29/19 10:38 PM, Paul wrote:
T wrote:
Hi All,

Windows provides a utility called filever.exe which will
tell you the revision of an exe file.Â* (You can also see this
through the gui with properties).

I would like to write my own Perl module to return the .exe's
version.Â* Does anyone know where the version information is
stored in an .exe file?Â* (I bet Paul does not even have to
look this one up.)

Many thanks,
-T

Why not find a representative sample of files first,
and try the techniques here ?

https://stackoverflow.com/questions/...-in-powershell

Then you can go off and craft a Perl module to do the same thing.

And when a file doesn't have a version, your Perl code
shouldn't return a version either. Remember that Microsoft
was never that "hungry for version control now". At one
time, patching articles referred to file sizes, as the
identifier of choice. "Replace the 123 byte file with
the 125 byte file" Yuck.

Whereas more modern OS partition content, should have
more metadata.

Mayayana probably has more experience with this than
I do. I haven't had a reason to ferret out version
info for some time.

The unthinkable is also possible.

https://docs.microsoft.com/en-us/pow...w=powershell-6


The only general comment I'd have about that idea,
is that you'd expect some forked commandlet to be slow,
as there'd be some sort of giant environment to fork.
I wouldn't expect that to be able to examine 100 files
per second. Whereas your Perl idea might.

Â*Â*Â* Paul



Hi Paul,

I was thinking of running an exe through hexedit, but
I could be looking at thousands of line.Â* EEEEE.

Also, the perl module will be running under Linux.

-T



I have been running filever.exe under Wine, but
poor STDERR sheds tears. Plus I kind of just wanted
to do it myself.

On 1/29/19 10:49 PM, T wrote:
On 1/29/19 10:47 PM, T wrote:
On 1/29/19 10:38 PM, Paul wrote:
T wrote:
Hi All,

Windows provides a utility called filever.exe which will
tell you the revision of an exe file.Â* (You can also see this
through the gui with properties).

I would like to write my own Perl module to return the .exe's
version.Â* Does anyone know where the version information is
stored in an .exe file?Â* (I bet Paul does not even have to
look this one up.)

Many thanks,
-T

Why not find a representative sample of files first,
and try the techniques here ?

https://stackoverflow.com/questions/...-in-powershell

Then you can go off and craft a Perl module to do the same thing.

And when a file doesn't have a version, your Perl code
shouldn't return a version either. Remember that Microsoft
was never that "hungry for version control now". At one
time, patching articles referred to file sizes, as the
identifier of choice. "Replace the 123 byte file with
the 125 byte file" Yuck.

Whereas more modern OS partition content, should have
more metadata.

Mayayana probably has more experience with this than
I do. I haven't had a reason to ferret out version
info for some time.

The unthinkable is also possible.

https://docs.microsoft.com/en-us/pow...w=powershell-6


The only general comment I'd have about that idea,
is that you'd expect some forked commandlet to be slow,
as there'd be some sort of giant environment to fork.
I wouldn't expect that to be able to examine 100 files
per second. Whereas your Perl idea might.

Â*Â*Â* Paul



Hi Paul,

I was thinking of running an exe through hexedit, but
I could be looking at thousands of line.Â* EEEEE.

Also, the perl module will be running under Linux.

-T



I have been running filever.exe under Wine, but
poor STDERR sheds tears.Â* Plus I kind of just wanted
to do it myself.





Looking at filever.exe itself I get:

$ WINEDEBUG=-all wine filever.exe filever.exe
--a-- W32i APP ENU 5.1.2600.0 shp 12,800 02-13-2018 filever.exe

or version 5.1.2600.0

Looking a hexedit, way down on the page, I find:

00002DC0 01 00 46 00 69 00 6C 00 65 00 56 00 65 00 72 00
..F.i.l.e.V.e.r.

00002DD0 73 00 69 00 6F 00 6E 00 00 00 00 00 35 00 2E 00
s.i.o.n.....5...

00002DE0 31 00 2E 00 32 00 36 00 30 00 30 00 2E 00 30 00
1...2.6.0.0...0.

00002DF0 20 00 28 00 58 00 50 00 43 00 6C 00 69 00 65 00
.(.X.P.C.l.i.e.

Or great, a nul after every character! Perl is going to
kick my ass if I try to read it as a string.

So look for
46 00 69 00 6C 00 65 00 56 00 65 00 72 00

The look for data that ends in a 0x20H as a terminator.


And I never did find the version in of itunes with hexedit:

$ WINEDEBUG=-all wine filever.exe java.exe
--a-- W32i APP ENU 7.0.800.15 shp 6,463,488 11-16-2015 java.exe


This will be interesting!

T wrote:
On 1/29/19 10:49 PM, T wrote:
On 1/29/19 10:47 PM, T wrote:
On 1/29/19 10:38 PM, Paul wrote:
T wrote:
Hi All,

Windows provides a utility called filever.exe which will
tell you the revision of an exe file. (You can also see this
through the gui with properties).

I would like to write my own Perl module to return the .exe's
version. Does anyone know where the version information is
stored in an .exe file? (I bet Paul does not even have to
look this one up.)

Many thanks,
-T

Why not find a representative sample of files first,
and try the techniques here ?

https://stackoverflow.com/questions/...-in-powershell


Then you can go off and craft a Perl module to do the same thing.

And when a file doesn't have a version, your Perl code
shouldn't return a version either. Remember that Microsoft
was never that "hungry for version control now". At one
time, patching articles referred to file sizes, as the
identifier of choice. "Replace the 123 byte file with
the 125 byte file" Yuck.

Whereas more modern OS partition content, should have
more metadata.

Mayayana probably has more experience with this than
I do. I haven't had a reason to ferret out version
info for some time.

The unthinkable is also possible.

https://docs.microsoft.com/en-us/pow...w=powershell-6


The only general comment I'd have about that idea,
is that you'd expect some forked commandlet to be slow,
as there'd be some sort of giant environment to fork.
I wouldn't expect that to be able to examine 100 files
per second. Whereas your Perl idea might.

Paul



Hi Paul,

I was thinking of running an exe through hexedit, but
I could be looking at thousands of line. EEEEE.

Also, the perl module will be running under Linux.

-T



I have been running filever.exe under Wine, but
poor STDERR sheds tears. Plus I kind of just wanted
to do it myself.





Looking at filever.exe itself I get:

$ WINEDEBUG=-all wine filever.exe filever.exe
--a-- W32i APP ENU 5.1.2600.0 shp 12,800 02-13-2018 filever.exe

or version 5.1.2600.0

Looking a hexedit, way down on the page, I find:

00002DC0 01 00 46 00 69 00 6C 00 65 00 56 00 65 00 72 00
..F.i.l.e.V.e.r.

00002DD0 73 00 69 00 6F 00 6E 00 00 00 00 00 35 00 2E 00
s.i.o.n.....5...

00002DE0 31 00 2E 00 32 00 36 00 30 00 30 00 2E 00 30 00
1...2.6.0.0...0.

00002DF0 20 00 28 00 58 00 50 00 43 00 6C 00 69 00 65 00
.(.X.P.C.l.i.e.

Or great, a nul after every character! Perl is going to
kick my ass if I try to read it as a string.

So look for
46 00 69 00 6C 00 65 00 56 00 65 00 72 00

The look for data that ends in a 0x20H as a terminator.


And I never did find the version in of itunes with hexedit:

$ WINEDEBUG=-all wine filever.exe java.exe
--a-- W32i APP ENU 7.0.800.15 shp 6,463,488 11-16-2015 java.exe


This will be interesting!

Are you sure you're the right person for this ?

Those double byte characters are wide characters, something
Windows now uses a lot of. And believe it or not, Linux is
fully armed for this stuff too.

The basic ASCII set maps into the double-byte characters as 0x00 0xYY
where the YY would be the regular ASCII part. If you specify the
correct character input routine to process a double byte character
string, nobody will be kicking your ass.

This is one of the issues for a text processing engine such as
AWK or GAWK. They're still in the "ASCII" universe, and incapable
of dealing with anything else. There is a certain degree of "niceless"
in being able to deal with bytes as a binary value or as an ASCII
character when writing script processing.

But today, if you think you're processing text, you have to be
ready for just about anything. If you still live your life in
1980, yes, just about everything will be kicking your ass.

The first time I ran into this, was when doing a home brew
version of GREP. I needed to search a huge file for something,
and wanted to write my own search code. And I soon discovered,
that the "word" I wanted to find in the OS, could either be
in single byte representation or double byte representation.
And I'd actually need to code up two searches to find every
occurrence.

I run into this when writing my "simple" 60 line C programs.
If I need to output a message to the screen

"Enter numbers to sum: "

I can do that with ASCII. Because I'm English, live in NA, and
am clueless. However, if someone makes me write a program with
"localization" support, then I suddenly discover the world isn't
ASCII any more. I have to broaden my horizons.

So how soon could such a brave new world affect me ?

As soon as I start processing filenames from NTFS, I'm going
to be exposed to double byte characters. Sometimes I will find the
first character is no longer 0x00 and it's something else, and
I see an E-grave printed on the screen, or a cedilla, or... whatever.

And that's what could end up in your hex sample above. If you
had a file where the compiler used Chinese characters for the
metadata stamp, then a "filever" program would need to deal with
it, and display it on screen appropriately.

In fact, it doesn't take too many exposures to stuff on the
computer, before you start to notice a theme. We're leaving
the ASCII single-byte universe, and more and more aspects
of the environment are different now.

As an example, take Notepad. The old Notepad would read ASCII.
The current version on Windows 10 has had some significant
performance improvements made to it. And when that happens,
you would suspect some other changes were made under the hood.

A text file could have 0xFE 0xFF at the beginning. Which is
a declaration we're leaving "ASCII station". You might also have
noticed how, when passing what should have been text files
to programs like GEDIT, GEDIT is throwing a wobbly when it reads
some of the Windows files now. Some of those files could have
double bytes without the proper declaration at the beginning.
While others have a prefix set of bytes, which help editors
determine the encoding present.

When I'm using a hex editor (such as HxD), I'm an "ASCII guy", especially
when the hex editor ("text display section") is not modern when
it comes to character representations. The canonical dual presentation
of the hex editor, has not been altered for modern times. And like
you, I read the screen and see "oh my, a null followed by an ASCII".
But it's really not that. And a proper parser, you'd be sending
wide character strings to it, and the wide representation uses
twice as many bytes as we used to use in the ASCII era.
When printed on the screen ("properly"), those NULLs would
disappear and there wouldn't be an "squares" on the screen or
anything. A 10 byte string with 5 NULLs and 5 ASCII would be
rendered on the screen as some French word with five characters
and an E-grave or a Cedilla. And if I work in Visual Studio or
even MINGW, I could access, say, "wprintf" instead of "printf"
and pass it wide characters or something.

Would PERL do that ? I would expect the author of PERL, a
linguistics specialist, to actually do that, and make the language
support modern things. But I don't follow PERL development
and can't say whether that's been done. AFAIK GAWK hasn't
been fixed, because it would be damn hard to fix. With PERL,
they could just change the version number, and change how
stuff is handled. And make people relearn everything.

*******

My lecture, is to prepare you for *this* .
Note the date - a train wreck was apparent fifteen years ago!

https://www.joelonsoftware.com/2003/...ts-no-excuses/

Paul

On 1/30/19 3:04 AM, Paul wrote:
T wrote:
On 1/29/19 10:49 PM, T wrote:
On 1/29/19 10:47 PM, T wrote:
On 1/29/19 10:38 PM, Paul wrote:
T wrote:
Hi All,

Windows provides a utility called filever.exe which will
tell you the revision of an exe file.Â* (You can also see this
through the gui with properties).

I would like to write my own Perl module to return the .exe's
version.Â* Does anyone know where the version information is
stored in an .exe file?Â* (I bet Paul does not even have to
look this one up.)

Many thanks,
-T

Why not find a representative sample of files first,
and try the techniques here ?

https://stackoverflow.com/questions/...-in-powershell


Then you can go off and craft a Perl module to do the same thing.

And when a file doesn't have a version, your Perl code
shouldn't return a version either. Remember that Microsoft
was never that "hungry for version control now". At one
time, patching articles referred to file sizes, as the
identifier of choice. "Replace the 123 byte file with
the 125 byte file" Yuck.

Whereas more modern OS partition content, should have
more metadata.

Mayayana probably has more experience with this than
I do. I haven't had a reason to ferret out version
info for some time.

The unthinkable is also possible.

https://docs.microsoft.com/en-us/pow...w=powershell-6


The only general comment I'd have about that idea,
is that you'd expect some forked commandlet to be slow,
as there'd be some sort of giant environment to fork.
I wouldn't expect that to be able to examine 100 files
per second. Whereas your Perl idea might.

Â*Â*Â* Paul



Hi Paul,

I was thinking of running an exe through hexedit, but
I could be looking at thousands of line.Â* EEEEE.

Also, the perl module will be running under Linux.

-T



I have been running filever.exe under Wine, but
poor STDERR sheds tears.Â* Plus I kind of just wanted
to do it myself.





Looking at filever.exe itself I get:

$ WINEDEBUG=-all wine filever.exe filever.exe
--a-- W32iÂ*Â* APP ENUÂ*Â*Â*Â*Â* 5.1.2600.0 shpÂ*Â*Â*Â* 12,800 02-13-2018
filever.exe

or version 5.1.2600.0

Looking a hexedit, way down on the page, I find:

00002DC0Â*Â* 01 00 46 00Â* 69 00 6C 00Â* 65 00 56 00Â* 65 00 72 00
..F.i.l.e.V.e.r.

00002DD0Â*Â* 73 00 69 00Â* 6F 00 6E 00Â* 00 00 00 00Â* 35 00 2E 00
s.i.o.n.....5...

00002DE0Â*Â* 31 00 2E 00Â* 32 00 36 00Â* 30 00 30 00Â* 2E 00 30 00
1...2.6.0.0...0.

00002DF0Â*Â* 20 00 28 00Â* 58 00 50 00Â* 43 00 6C 00Â* 69 00 65 00
.(.X.P.C.l.i.e.

Or great, a nul after every character!Â* Perl is going to
kick my ass if I try to read it as a string.

So look for
Â*Â* 46 00Â* 69 00 6C 00Â* 65 00 56 00Â* 65 00 72 00

The look for data that ends in a 0x20H as a terminator.


And I never did find the version in of itunes with hexedit:

$ WINEDEBUG=-all wine filever.exe java.exe
--a-- W32iÂ*Â* APP ENUÂ*Â*Â*Â*Â* 7.0.800.15 shpÂ* 6,463,488 11-16-2015 java.exe


This will be interesting!

Are you sure you're the right person for this ?

Those double byte characters are wide characters, something
Windows now uses a lot of. And believe it or not, Linux is
fully armed for this stuff too.

The basic ASCII set maps into the double-byte characters as 0x00 0xYY
where the YY would be the regular ASCII part. If you specify the
correct character input routine to process a double byte character
string, nobody will be kicking your ass.

This is one of the issues for a text processing engine such as
AWK or GAWK. They're still in the "ASCII" universe, and incapable
of dealing with anything else. There is a certain degree of "niceless"
in being able to deal with bytes as a binary value or as an ASCII
character when writing script processing.

But today, if you think you're processing text, you have to be
ready for just about anything. If you still live your life in
1980, yes, just about everything will be kicking your ass.

The first time I ran into this, was when doing a home brew
version of GREP. I needed to search a huge file for something,
and wanted to write my own search code. And I soon discovered,
that the "word" I wanted to find in the OS, could either be
in single byte representation or double byte representation.
And I'd actually need to code up two searches to find every
occurrence.

I run into this when writing my "simple" 60 line C programs.
If I need to output a message to the screen

Â*Â* "Enter numbers to sum: "

I can do that with ASCII. Because I'm English, live in NA, and
am clueless. However, if someone makes me write a program with
"localization" support, then I suddenly discover the world isn't
ASCII any more. I have to broaden my horizons.

So how soon could such a brave new world affect me ?

As soon as I start processing filenames from NTFS, I'm going
to be exposed to double byte characters. Sometimes I will find the
first character is no longer 0x00 and it's something else, and
I see an E-grave printed on the screen, or a cedilla, or... whatever.

And that's what could end up in your hex sample above. If you
had a file where the compiler used Chinese characters for the
metadata stamp, then a "filever" program would need to deal with
it, and display it on screen appropriately.

In fact, it doesn't take too many exposures to stuff on the
computer, before you start to notice a theme. We're leaving
the ASCII single-byte universe, and more and more aspects
of the environment are different now.

As an example, take Notepad. The old Notepad would read ASCII.
The current version on Windows 10 has had some significant
performance improvements made to it. And when that happens,
you would suspect some other changes were made under the hood.

A text file could have 0xFE 0xFF at the beginning. Which is
a declaration we're leaving "ASCII station". You might also have
noticed how, when passing what should have been text files
to programs like GEDIT, GEDIT is throwing a wobbly when it reads
some of the Windows files now. Some of those files could have
double bytes without the proper declaration at the beginning.
While others have a prefix set of bytes, which help editors
determine the encoding present.

When I'm using a hex editor (such as HxD), I'm an "ASCII guy", especially
when the hex editor ("text display section") is not modern when
it comes to character representations. The canonical dual presentation
of the hex editor, has not been altered for modern times. And like
you, I read the screen and see "oh my, a null followed by an ASCII".
But it's really not that. And a proper parser, you'd be sending
wide character strings to it, and the wide representation uses
twice as many bytes as we used to use in the ASCII era.
When printed on the screen ("properly"), those NULLs would
disappear and there wouldn't be an "squares" on the screen or
anything. A 10 byte string with 5 NULLs and 5 ASCII would be
rendered on the screen as some French word with five characters
and an E-grave or a Cedilla. And if I work in Visual Studio or
even MINGW, I could access, say, "wprintf" instead of "printf"
and pass it wide characters or something.

Would PERL do that ? I would expect the author of PERL, a
linguistics specialist, to actually do that, and make the language
support modern things. But I don't follow PERL development
and can't say whether that's been done. AFAIK GAWK hasn't
been fixed, because it would be damn hard to fix. With PERL,
they could just change the version number, and change how
stuff is handled. And make people relearn everything.

*******

My lecture, is to prepare you for *this* .
Note the date - a train wreck was apparent fifteen years ago!

https://www.joelonsoftware.com/2003/...ts-no-excuses/


Â*Â* Paul



Hi Paul,

Perl 6 has Unicode out the ying yang.

I prefer to just look at things as binary rather than suffer the slings
and arrows involved with unicode. And I am really, really handy with
regex. I can manually dump those extra characters faster than you can
blink. Maybe this will be the one insistence when I use UTF 16.

I have had instances where I got "UTF who knows" back from system calls
in Linux before. It can be a pain in the ass if you don't realize
what is happening.

I will probably look over your lecture tomorrow.

-T

T wrote:
On 1/29/19 10:49 PM, T wrote:
On 1/29/19 10:47 PM, T wrote:
On 1/29/19 10:38 PM, Paul wrote:
T wrote:
Hi All,

Windows provides a utility called filever.exe which will
tell you the revision of an exe file. (You can also see this
through the gui with properties).

I would like to write my own Perl module to return the .exe's
version. Does anyone know where the version information is
stored in an .exe file? (I bet Paul does not even have to
look this one up.)

Many thanks,
-T

Why not find a representative sample of files first,
and try the techniques here ?

https://stackoverflow.com/questions/...-in-powershell


Then you can go off and craft a Perl module to do the same thing.

And when a file doesn't have a version, your Perl code
shouldn't return a version either. Remember that Microsoft
was never that "hungry for version control now". At one
time, patching articles referred to file sizes, as the
identifier of choice. "Replace the 123 byte file with
the 125 byte file" Yuck.

Whereas more modern OS partition content, should have
more metadata.

Mayayana probably has more experience with this than
I do. I haven't had a reason to ferret out version
info for some time.

The unthinkable is also possible.

https://docs.microsoft.com/en-us/pow...w=powershell-6


The only general comment I'd have about that idea,
is that you'd expect some forked commandlet to be slow,
as there'd be some sort of giant environment to fork.
I wouldn't expect that to be able to examine 100 files
per second. Whereas your Perl idea might.

Paul



Hi Paul,

I was thinking of running an exe through hexedit, but
I could be looking at thousands of line. EEEEE.

Also, the perl module will be running under Linux.

-T



I have been running filever.exe under Wine, but
poor STDERR sheds tears. Plus I kind of just wanted
to do it myself.





Looking at filever.exe itself I get:

$ WINEDEBUG=-all wine filever.exe filever.exe
--a-- W32i APP ENU 5.1.2600.0 shp 12,800 02-13-2018 filever.exe

or version 5.1.2600.0

Looking a hexedit, way down on the page, I find:

00002DC0 01 00 46 00 69 00 6C 00 65 00 56 00 65 00 72 00
..F.i.l.e.V.e.r.

00002DD0 73 00 69 00 6F 00 6E 00 00 00 00 00 35 00 2E 00
s.i.o.n.....5...

00002DE0 31 00 2E 00 32 00 36 00 30 00 30 00 2E 00 30 00
1...2.6.0.0...0.

00002DF0 20 00 28 00 58 00 50 00 43 00 6C 00 69 00 65 00
.(.X.P.C.l.i.e.

Or great, a nul after every character! Perl is going to
kick my ass if I try to read it as a string.

So look for
46 00 69 00 6C 00 65 00 56 00 65 00 72 00

The look for data that ends in a 0x20H as a terminator.


And I never did find the version in of itunes with hexedit:

$ WINEDEBUG=-all wine filever.exe java.exe
--a-- W32i APP ENU 7.0.800.15 shp 6,463,488 11-16-2015 java.exe


This will be interesting!

https://perldoc.perl.org/perlunicode.html

Scoop up some bytes, starting at a certain offset, and
pass that to the appropriate routine.

You can see they made more of an attempt than GAWK made.
Which is understandable, as supporting these ideas makes
life much much harder.

When you write your code, you may have older executables
with ASCII, and newer ones with the double byte encoding.
You may have to search for some pattern or bit elsewhere
in the header, to specifically select the correct encoding.
As using an adaptive process (i.e. "what smells right")
is a lot harder to do error-free. The "every second byte
is 0x00" thing, is more of a North American thing. You cannot
use that observation to hammer that stuff out of existence.

And you're writing "defensive code", not "pleasing foreigners".

This is especially true of Windows 10, where the file
system is full of "land mines", and if you really really
expect your code to run without hanging, you bloody well
better have considered all the possibilities. What these
changes are actually achieving, is they're pushing hobby
programmers into the nearest dumpster :-/ If you expect
your program to survive even the normal mix of customers,
you have to put the extra effort into coding the program
well. A person with bad ASCII habits (that's me), is
going to have a lot of trouble adapting. Like, if I had
to do what you're doing right now, I'd have to find my
sample program, the one I put all the wide routines in,
to remind me how to do it.

I have this problem, with trivial scans of the file system.
I downloaded some web page full of "strange characters" in the
file names, and sure enough, the program I wrote was fine for
a while, until it hit that directory. Yes, I'm not ashamed to
admit, it was easier to delete those files, than fix the program :-/
You can get away with that, when there's only one disk to
analyze and then the program goes back in the drawer.

Paul

"Paul" wrote

| I would like to write my own Perl module to return the .exe's
| version. Does anyone know where the version information is
| stored in an .exe file?

1) Windows API:

Look up VerQueryValue, which can be used with the Perl
Win32 library. Though, of course, only a Perl nut would
do that kind of thing. But anyone using Perl is already a
nut. So...

(It also requires a couple of other API functions. It's all in
the MSDN docs.)

2) Windows Script Host/VBScript

FileSystemObject, from the WindowsScriptHost and probably
creatable via Perl as a COM object, has a method GetFileVersion.
Very simple. You could even write a VBS and call that to do the job.


3) Direct file parsing of resource section in a PE file:

The data itself is in the resource section of a PE file.
The subsection starts with:

VS_VERSION_INFO

It's a unicode string, so there's a null between each
character. If you want to hunt for it directly you can start
from the end of the file.

If you want to parse the resource section, there's a sample
here in vbscript:

https://www.jsware.net/jsware/scrfiles.php5#iconextr

The scripts in the download parse the resource section of
a PE file directly, on the byte level. But it's complex. The PE
header is gigantic, with lots of pointers. You find the resource
marker, get the pointer to the offset in the file.... There's
an info text file in the download that explains how the script
works. One would need to adapt that to look for the version
resource, and similarly follow the pointers. (The scripts in the
download look for icon resources and extract the data to
reconstitute those.)

Or it could be
brute-hacked by just looking for VS_VERSION_INFO. One could
also look for FileVersion, but the closer you try to get through
hacking, the riskier it is. That string could exist in the file
in a different context. In other words, if you find the offset and
data size in the header then you know you have the right data.
If you look for a string you might end up in the middle of string
resources and retrive a version full of nulls or nonsense.

Once the data offset is found, the unicode
data has to be parsed. I don't remember the details offhand,
but there's probably a section marker and maybe a string length
marker for the data in question. There may also be a product
version number. For instance, Acme Office 5.0.1 might have
aoffice.exe v. 1.22.8.

Version info seems to be especially sloppy. And there can
be language versions of the data. So, for instance, the
English strings would probably be somehow marked with H409.
(1033. The English codepage ID.)

That's probably why there's VerQueryValue. Microsoft is
basically saying, "Hey, this is a mess. What do you need?
I'll get it for you."

For all those reasons, if I were using Perl and it didn't have
a function, I think I'd use option #2.

On 30/01/2019 07.47, T wrote:
On 1/29/19 10:38 PM, Paul wrote:
T wrote:


Hi Paul,

I was thinking of running an exe through hexedit, but
I could be looking at thousands of line.Â* EEEEE.

Also, the perl module will be running under Linux.

Then just use the "file" command:

Legolas:/windows/C/Windows # file *exe
HelpPane.exe: PE32+ executable (GUI) x86-64, for MS Windows
bfsvc.exe: PE32+ executable (console) x86-64, for MS Windows
explorer.exe: PE32+ executable (GUI) x86-64, for MS Windows
hh.exe: PE32+ executable (GUI) x86-64, for MS Windows
notepad.exe: PE32+ executable (GUI) x86-64, for MS Windows
regedit.exe: PE32+ executable (GUI) x86-64, for MS Windows
splwow64.exe: PE32+ executable (GUI) x86-64, for MS Windows
winhlp32.exe: PE32 executable (GUI) Intel 80386, for MS Windows
write.exe: PE32+ executable (GUI) x86-64, for MS Windows
Legolas:/windows/C/Windows #



--
Cheers, Carlos.

On 1/30/19 4:28 AM, Paul wrote:
T wrote:
On 1/29/19 10:49 PM, T wrote:
On 1/29/19 10:47 PM, T wrote:
On 1/29/19 10:38 PM, Paul wrote:
T wrote:
Hi All,

Windows provides a utility called filever.exe which will
tell you the revision of an exe file.Â* (You can also see this
through the gui with properties).

I would like to write my own Perl module to return the .exe's
version.Â* Does anyone know where the version information is
stored in an .exe file?Â* (I bet Paul does not even have to
look this one up.)

Many thanks,
-T

Why not find a representative sample of files first,
and try the techniques here ?

https://stackoverflow.com/questions/...-in-powershell


Then you can go off and craft a Perl module to do the same thing.

And when a file doesn't have a version, your Perl code
shouldn't return a version either. Remember that Microsoft
was never that "hungry for version control now". At one
time, patching articles referred to file sizes, as the
identifier of choice. "Replace the 123 byte file with
the 125 byte file" Yuck.

Whereas more modern OS partition content, should have
more metadata.

Mayayana probably has more experience with this than
I do. I haven't had a reason to ferret out version
info for some time.

The unthinkable is also possible.

https://docs.microsoft.com/en-us/pow...w=powershell-6


The only general comment I'd have about that idea,
is that you'd expect some forked commandlet to be slow,
as there'd be some sort of giant environment to fork.
I wouldn't expect that to be able to examine 100 files
per second. Whereas your Perl idea might.

Â*Â*Â* Paul



Hi Paul,

I was thinking of running an exe through hexedit, but
I could be looking at thousands of line.Â* EEEEE.

Also, the perl module will be running under Linux.

-T



I have been running filever.exe under Wine, but
poor STDERR sheds tears.Â* Plus I kind of just wanted
to do it myself.





Looking at filever.exe itself I get:

$ WINEDEBUG=-all wine filever.exe filever.exe
--a-- W32iÂ*Â* APP ENUÂ*Â*Â*Â*Â* 5.1.2600.0 shpÂ*Â*Â*Â* 12,800 02-13-2018
filever.exe

or version 5.1.2600.0

Looking a hexedit, way down on the page, I find:

00002DC0Â*Â* 01 00 46 00Â* 69 00 6C 00Â* 65 00 56 00Â* 65 00 72 00
..F.i.l.e.V.e.r.

00002DD0Â*Â* 73 00 69 00Â* 6F 00 6E 00Â* 00 00 00 00Â* 35 00 2E 00
s.i.o.n.....5...

00002DE0Â*Â* 31 00 2E 00Â* 32 00 36 00Â* 30 00 30 00Â* 2E 00 30 00
1...2.6.0.0...0.

00002DF0Â*Â* 20 00 28 00Â* 58 00 50 00Â* 43 00 6C 00Â* 69 00 65 00
.(.X.P.C.l.i.e.

Or great, a nul after every character!Â* Perl is going to
kick my ass if I try to read it as a string.

So look for
Â*Â* 46 00Â* 69 00 6C 00Â* 65 00 56 00Â* 65 00 72 00

The look for data that ends in a 0x20H as a terminator.


And I never did find the version in of itunes with hexedit:

$ WINEDEBUG=-all wine filever.exe java.exe
--a-- W32iÂ*Â* APP ENUÂ*Â*Â*Â*Â* 7.0.800.15 shpÂ* 6,463,488 11-16-2015 java.exe


This will be interesting!

https://perldoc.perl.org/perlunicode.html

Scoop up some bytes, starting at a certain offset, and
pass that to the appropriate routine.

You can see they made more of an attempt than GAWK made.
Which is understandable, as supporting these ideas makes
life much much harder.

When you write your code, you may have older executables
with ASCII, and newer ones with the double byte encoding.
You may have to search for some pattern or bit elsewhere
in the header, to specifically select the correct encoding.
As using an adaptive process (i.e. "what smells right")
is a lot harder to do error-free. The "every second byte
is 0x00" thing, is more of a North American thing. You cannot
use that observation to hammer that stuff out of existence.

And you're writing "defensive code", not "pleasing foreigners".

This is especially true of Windows 10, where the file
system is full of "land mines", and if you really really
expect your code to run without hanging, you bloody well
better have considered all the possibilities. What these
changes are actually achieving, is they're pushing hobby
programmers into the nearest dumpster :-/ If you expect
your program to survive even the normal mix of customers,
you have to put the extra effort into coding the program
well. A person with bad ASCII habits (that's me), is
going to have a lot of trouble adapting. Like, if I had
to do what you're doing right now, I'd have to find my
sample program, the one I put all the wide routines in,
to remind me how to do it.

I have this problem, with trivial scans of the file system.
I downloaded some web page full of "strange characters" in the
file names, and sure enough, the program I wrote was fine for
a while, until it hit that directory. Yes, I'm not ashamed to
admit, it was easier to delete those files, than fix the program :-/
You can get away with that, when there's only one disk to
analyze and then the program goes back in the drawer.

Â*Â* Paul

Hi Paul,

Still gathering data.a

I notice that filever goes like the wind, even on very large
programs. So I was wondering if there was some kind of header
hidden away that was easy to get at.

-T

On 1/30/19 6:26 AM, Carlos E.R. wrote:
On 30/01/2019 07.47, T wrote:
On 1/29/19 10:38 PM, Paul wrote:
T wrote:


Hi Paul,

I was thinking of running an exe through hexedit, but
I could be looking at thousands of line.Â* EEEEE.

Also, the perl module will be running under Linux.

Then just use the "file" command:

Legolas:/windows/C/Windows # file *exe
HelpPane.exe: PE32+ executable (GUI) x86-64, for MS Windows
bfsvc.exe: PE32+ executable (console) x86-64, for MS Windows
explorer.exe: PE32+ executable (GUI) x86-64, for MS Windows
hh.exe: PE32+ executable (GUI) x86-64, for MS Windows
notepad.exe: PE32+ executable (GUI) x86-64, for MS Windows
regedit.exe: PE32+ executable (GUI) x86-64, for MS Windows
splwow64.exe: PE32+ executable (GUI) x86-64, for MS Windows
winhlp32.exe: PE32 executable (GUI) Intel 80386, for MS Windows
write.exe: PE32+ executable (GUI) x86-64, for MS Windows
Legolas:/windows/C/Windows #

Hi Carlos,

I will not be using Windows to do this, which is why I
wanted to find out what the specification was. But
thank you anyway!

-T

On 1/30/19 6:01 AM, Mayayana wrote:
"Paul" wrote

| I would like to write my own Perl module to return the .exe's
| version. Does anyone know where the version information is
| stored in an .exe file?

1) Windows API:

Look up VerQueryValue, which can be used with the Perl
Win32 library.



Win32::API - Get file version information

Borkur . Gudjonsson Fri, 19 May 2000 03:26:39 -0700

Hello.
I'm trying to retrieve version information from file(s).

It seems that I have to use 3 Win32 functions:
1. GetFileVersionInfoSize()
which gets the size of the version information.
2. GetFileVersionInfo()
which retrieves the version information buffer.
3. VerQueryValue()
to retrieve selected version information.

Now, 1. and 2. work OK but 3. doesn't work!
Can someone help me please?

Regards,
Borkur Gudjonsson

Though, of course, only a Perl nut would
do that kind of thing. But anyone using Perl is already a
nut. So...

What ?!?! WHAT ?!?!? "nut" !!!! Why, Why, Why.


Okay, you got me. I can't help myself. I absolutely adore Perl.
By the way, Perl 6 is a YUGE improvement over Perl 5. Cleaned
up a not of the stupid nonsense in Perl 5, such as the
subroutine headers.


(It also requires a couple of other API functions. It's all in
the MSDN docs.)

2) Windows Script Host/VBScript

FileSystemObject, from the WindowsScriptHost and probably
creatable via Perl as a COM object, has a method GetFileVersion.
Very simple. You could even write a VBS and call that to do the job.


3) Direct file parsing of resource section in a PE file:

The data itself is in the resource section of a PE file.
The subsection starts with:

VS_VERSION_INFO

It's a unicode string, so there's a null between each
character. If you want to hunt for it directly you can start
from the end of the file.

If you want to parse the resource section, there's a sample
here in vbscript:

https://www.jsware.net/jsware/scrfiles.php5#iconextr

The scripts in the download parse the resource section of
a PE file directly, on the byte level. But it's complex. The PE
header is gigantic, with lots of pointers. You find the resource
marker, get the pointer to the offset in the file.... There's
an info text file in the download that explains how the script
works. One would need to adapt that to look for the version
resource, and similarly follow the pointers. (The scripts in the
download look for icon resources and extract the data to
reconstitute those.)

Or it could be
brute-hacked by just looking for VS_VERSION_INFO. One could
also look for FileVersion, but the closer you try to get through
hacking, the riskier it is. That string could exist in the file
in a different context. In other words, if you find the offset and
data size in the header then you know you have the right data.
If you look for a string you might end up in the middle of string
resources and retrive a version full of nulls or nonsense.

This is what I am afraid of.


Once the data offset is found, the unicode
data has to be parsed. I don't remember the details offhand,
but there's probably a section marker and maybe a string length
marker for the data in question. There may also be a product
version number. For instance, Acme Office 5.0.1 might have
aoffice.exe v. 1.22.8.

Version info seems to be especially sloppy. And there can
be language versions of the data. So, for instance, the
English strings would probably be somehow marked with H409.
(1033. The English codepage ID.)

That's probably why there's VerQueryValue. Microsoft is
basically saying, "Hey, this is a mess. What do you need?
I'll get it for you."

For all those reasons, if I were using Perl and it didn't have
a function, I think I'd use option #2.

There are some sweet dot net system calls for this too.

Unfortunately, I will not be running this on Windows, so
that is why I need to know the specification for versioning.

-T

"T" wrote

| It seems that I have to use 3 Win32 functions:
| 1. GetFileVersionInfoSize()
| which gets the size of the version information.
| 2. GetFileVersionInfo()
| which retrieves the version information buffer.
| 3. VerQueryValue()
| to retrieve selected version information.
|
| Now, 1. and 2. work OK but 3. doesn't work!
| Can someone help me please?
|

I don't get it. Was someone else asking about that, or you?
You're on Linux but running under WINE? I don't know
whether WINE has all the APIs you need, and they're
somewhat funky, so it's anyone's guess whether WINE has
implemented them in the same way. I think it would be easiest
to just install the Windows Script Host under WINE and use
that.

If you want to just walk the file bytes then see my icon
extractor and look up the details of the VS_VERSION_INFO
resource structure.

You didn't indicate whether you can use the API, but here's a
basic rundown:
GetFileVersionInfoSize returns the size of the data. You then
allocate a byte array of that size (LSz)

LSz = GetFileVersionInfoSize(filepath, junk)
LRet = GetFileVersionInfo(filepath, junk, LSz, x)
If LRet 0 then
lret = VerQueryValue(x, "\", BufSz, LSz)
if LRet 0 then
CopyMemory(vVS_FIXEDFILEINFO, BufSz, LSz)


x here is a pointer to the address of the first byte of the
allocated array. LSz is the size of the array in bytes. BufSz
is how many bytes were written to the array.
The system writes the data to that array. You then copy
that into a VS_FIXEDFILEINFO structure with CopyMemory.
(RTLMoveMemory)

VS_FIXEDFILEINFO {
DWORD dwSignature;
DWORD dwStrucVersion;
DWORD dwFileVersionMS;
DWORD dwFileVersionLS;
DWORD dwProductVersionMS;
DWORD dwProductVersionLS;
DWORD dwFileFlagsMask;
DWORD dwFileFlags;
DWORD dwFileOS;
DWORD dwFileType;
DWORD dwFileSubtype;
DWORD dwFileDateMS;
DWORD dwFileDateLS;
} VS_FIXEDFILEINFO;

The structure is tricky. Another way of writing it is like this:

DWORD dwSignature
DWORD dwStrucVersion
FileVerPart2 As Integer
FileVerPart1 As Integer
FileVerPart4 As Integer
FileVerPart3 As Integer

You then collect the parts like so, converting
each part to a string and adding periods:

part1.part2.part3.part4
to get the actual version string

On 30/01/2019 20.23, T wrote:
On 1/30/19 6:26 AM, Carlos E.R. wrote:
On 30/01/2019 07.47, T wrote:
On 1/29/19 10:38 PM, Paul wrote:
T wrote:


Hi Paul,

I was thinking of running an exe through hexedit, but
I could be looking at thousands of line.Â* EEEEE.

Also, the perl module will be running under Linux.

Then just use the "file" command:

Legolas:/windows/C/Windows # file *exe
HelpPane.exe: PE32+ executable (GUI) x86-64, for MS Windows
bfsvc.exe:Â*Â*Â* PE32+ executable (console) x86-64, for MS Windows
explorer.exe: PE32+ executable (GUI) x86-64, for MS Windows
hh.exe:Â*Â*Â*Â*Â*Â* PE32+ executable (GUI) x86-64, for MS Windows
notepad.exe:Â* PE32+ executable (GUI) x86-64, for MS Windows
regedit.exe:Â* PE32+ executable (GUI) x86-64, for MS Windows
splwow64.exe: PE32+ executable (GUI) x86-64, for MS Windows
winhlp32.exe: PE32 executable (GUI) Intel 80386, for MS Windows
write.exe:Â*Â*Â* PE32+ executable (GUI) x86-64, for MS Windows
Legolas:/windows/C/Windows #

Hi Carlos,

I will not be using Windows to do this, which is why I
wanted to find out what the specification was.Â* But
thank you anyway!

Didn't you notice that I was doing that in Linux? ;-)

Hint: look at the path slashes, the type of prompt...

--
Cheers, Carlos.