If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
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 |
Ads |
#2
|
|||
|
|||
filever?
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 |
#3
|
|||
|
|||
filever?
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 |
#4
|
|||
|
|||
filever?
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. |
#5
|
|||
|
|||
filever?
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! |
#6
|
|||
|
|||
filever?
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 |
#7
|
|||
|
|||
filever?
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 |
#8
|
|||
|
|||
filever?
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 |
#9
|
|||
|
|||
filever?
"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. |
#10
|
|||
|
|||
filever?
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. |
#11
|
|||
|
|||
filever?
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 |
#12
|
|||
|
|||
filever?
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 |
#13
|
|||
|
|||
filever?
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 |
#14
|
|||
|
|||
filever?
"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 |
#15
|
|||
|
|||
filever?
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. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|