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 |
#76
|
|||
|
|||
filever?
On 03/02/2019 04.58, T wrote:
On 2/2/19 5:18 AM, Mayayana wrote: "T" wrote | | I was looking at a corrupted exe.Â* Good one all have | what I am looking for Â*Â* Ah. But they might not. Especially with DLLs. You have to be prepared for some or all missing. It might not even have a resource section. I am only going after .exe's.Â* At the moment, I don't care at all about DLL's. There are .exe's without resources. -- Cheers, Carlos. |
Ads |
#77
|
|||
|
|||
filever?
"T" wrote
| If I know where to point, I can easily find it with Perl. | Pointer refers to a variable that's a numeric address. x = 3 y = "this is a string" Both variables, in Win32, are 4 byte numbers. x will be 4 bytes that represent a number: 03 00 00 00 y will be a pointer to a memory address. It might be 34992881, for instance. That means the string is stored at that memory address. So you have something like GetVersionEx(x) The variable x is what's known in C++ as a struct. x itself still holds a number, but it points to the address of the struct. The struct consists of a number of variables stored together. This gets complicated in something like Perl because your scalar variable seems to be basically a variant. Which means Perl is hiding the details from you to keep it simple. The simplicity makes it easier to use but harder to understand what's actually going on. That's also a factor in speed. As an interpreted, scripting language there are limits to how fast it can be. It's sort of like a cook's window in a restaurant. You're the waiter. You go to the window and ask for the Salisbury steak special. The cook makes it and puts it on the window ledge for you. You have no means to cook it yourself. That middleman design gives you a lot of options with minimal complication. You don't have to actually cook the hamburger or arrange the lettuce and tomato on the plate. But it also adds inefficiency. You have to wait for the cook, and communicating with the cook takes time. (Java and .Net are similar. Wrapper software that does the work and lets you use simplified methods. Of course, the Win32 API is also a wrapper system. But it's at a lower level, with less baggage. So it's both faster and more complicated.) I don't know any Perl and to my mind life's too short for such ugly stuff. There's no excuse for such confusing terseness. (Though it will help you avoid being beat up in the slums of LinuxLand. They love that esoteric stuff. But you can look it up easily enough. And I assume there are docs for the Win32 API Perl library. The main point is just that you have to get used to the function format, and you have to know what function you want: returnValue = FunctionName(parameter list) Another example: GetOpenFileName can be used to show a file browsing dialogue window and then get the path of the file selected. Again, it has only one parameter, but that's a complex struct. | I just can't find where to point in the docs. Do you | know where these docs are? That's another complicated story, I'm afraid. MSDN. This might not be of value to you, especially if you prefer Linux. And most of it is intended for GUI software, while Perl seems to be mainly used for grunt work, like searching and organizing files. If you want to get the docs, see he https://www.jsware.net/jsware/hxs2chm.php5 It used to be that Microsoft offered docs for various things. You could download the speech API docs, Office docs, etc. These days they only offer it as one gigantic package, meant to be used with Visual Studio. There's a download for each Windows version. Inside are docs for everything, arranged as a large number of HXS files. HXS files are basically a corrupted version of CHM files, changed just enough so that you can't use them without a special reader program. The good news is that it's all still there and it can be cleaned up. The link above is to a VBScript-based utility that can be used to convert the HXS files. There are two options. One is to convert any or all HXS to CHM. So, for example, you can convert the Windows shell docs, or the accesibility docs, or the IE document object model docs. The other option is to take the whole mess, unpack the HXS files into a folder tree, and create one giant help system that works in a webpage. That's more clunky and less organized, but it provides you with a master index, so you don't have to know which HXS has the GetOpenFileName docs, for instance. This stuff is all, also, online. GetOpenFileName: https://docs.microsoft.com/en-us/win...topenfilenamea Notice there are also more complications there. First is that MS have come up with a new function for file browsing. That's fine. But it won't work on XP or earlier. And Microsoft docs tend to be marketing-tinged. You have to read through that. They also just plain lie in some cases. Note that the supported systems spec at the bottom of the page says it needs at least Win2000 Pro. That's a lie. The function goes all the way back to Win95, as most Win32 API calls do. Microsoft like to pretend their older systems don't exist. They actually change the docs to deny the existence of them! My 1998 copy of MSDN docs says this: Windows NT: Requires version 3.1 or later. Windows: Requires Windows 95 or later. They actually had to deliberately make the effort to change the docs in order to provide false and misleading information. In some cases I've seen them pretend that functions won't work on XP. But in general Microsoft are pretty good at providing docs. They have to, for commerical developers. It's a kind of tradition, going back to the time when they maintained their monopoly, in part, by catering to programmers. They also provide sample code. Windows is far better in that sense than Linux. A man page is not docs. It's just a cheat sheet. |
#78
|
|||
|
|||
filever?
On 04/02/2019 05.33, T wrote:
On 2/3/19 7:20 PM, Mayayana wrote: "T" wrote | Â*Â*Â* That's probably not the right syntax, but you can get | the idea from that. The Perl library takes in the request, | translates it, and makes the call itself. That would be a | very clunky way to write software, but you could use it in | Windows or under WINE to accomplish all sorts of things. | | | | yes, I have seen all that.Â* I can't read C so it is not of much use. You should learn at least to read C, regardless if you use Perl or whatever, because the documentation you need to read assumes C. Both Windows and Linux provide C header files (.h) to access structures, and if the equivalent file doesn't exist in your language of choice you have to translate the .h to Perl or whatever, yourself. Â*Â*Â* It has nothing to do with C. You just have to know what to call, which is in the MSDN docs. It might not be of any use to you, but you can do it. The file version functions are an example. But I don't know how complicated it might be for Perl with datatypes. For instance, GetVersionEx returns the Windows version info. It's a very simple call. But it returns a pointer to a data structure. So Perl would need to provide a way for you to access that. If I know where to point, I can easily find it with Perl. I just can't find where to point in the docs.Â* Do you know where these docs are? Windows internals documents. Several expensive books. Start he https://en.wikipedia.org/wiki/Microsoft_Developer_Network -- Cheers, Carlos. |
#79
|
|||
|
|||
filever?
"T" wrote
| And you can't just read it in as a string in the first place? | | If will, but it "encodes" you, usually UTF8. You | lose your nuls, etc. Ah. That could work to your advantage. That's how I optimized the speed of my VBScript version. Though UTF8 might get messy. Perl will run into loads of invalid UTF-8 in an EXE. But if it can do a unicode-16, 2-bytes per character conversion then you can use my VBS sample. That's what I'm doing the OpenTextFile(Arg, 1, False, -1) Arg = file path 1 = open for reading False = don't create it if it doesn't exist -1 = open for a unicode read A quick search indicates Perl might use "UTF-16" to refer to Windows unicode, but I'm not sure. |
#80
|
|||
|
|||
filever?
"Carlos E.R." wrote
| You should learn at least to read C, regardless if you use Perl or | whatever, because the documentation you need to read assumes C. Both | Windows and Linux provide C header files (.h) to access structures, and | if the equivalent file doesn't exist in your language of choice you have | to translate the .h to Perl or whatever, yourself. | C/C++ is really not necesary to use this stuff in Perl. He just has to know how to make the calls from Perl, and how to deal with the Perl data types. Data stored in memory is not inherently C or any other language. | I just can't find where to point in the docs. Do you | know where these docs are? | | Windows internals documents. Several expensive books. Start he | | https://en.wikipedia.org/wiki/Microsoft_Developer_Network | Ick. Yes. Anyone who approaches it that way will probably buy lots of expensive books and dubious certifications. But it's not necessary unless you're a sizable commercial company that has money to burn and wants to be an insider, with advance notice of new products and APIs. I've been writing Windows software for 20 years and never once bought an official Microsoft book or joined their overpriced club. And these days most of what they're selling is .Net transitioning to Metro trinket apps. They're playing down Win32 API and desktop software for anyone but commercial partners like Adobe. They'd much prefer you make a Metro app and give them a 30% cut of your sales. Of course, there won't be any sales because no one needs Metro apps, but why dwell on technical nitpicking? I just gave him 2 better ways to get the info: Microsoft's online docs or the SDK download. There's also plenty of help around. One need only search for an API function name to find discussions. The only place not to go is the Microsoft forums. They're little more than a filtered marketing venue, run and moderated by Microsofties: "Thank you so much for asking your question today. Please restate your question and include your Windows version, computer details, shirt size, and astrological chart. Once you do I can explain more clearly that your question is not suitable for this forum. Thank you and have a super good day." |
#81
|
|||
|
|||
filever?
T wrote:
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 There's source available for this one. You'll need an account to download the tiny ZIP. I've downloaded stuff here before, which is why I had the account sitting around. The program is "showver.cpp", a program demonstrating the VersionInfo library in Windows. It's possible Windows 10 has extended the winver.h contents, such that the author of this program somewhere around 2002, wouldn't be aware of any newer executable variants. https://www.codeproject.com/Articles...-display-progr VERSIONINFO for file "version.dll": (type:0) Signatu feef04bd StrucVersion: 1.0 FileVersion: 5.1.2600.5512 ProductVersion: 5.1.2600.5512 FileFlagsMask: 0x3f FileFlags: 0 FileOS: VOS_NT_WINDOWS32 FileType: VFT_DLL FileDate: 0.0 LangID: 040904B0 CompanyName : Microsoft Corporation FileDescription : Version Checking and File Installation Libraries FileVersion : 5.1.2600.5512 (xpsp.080413-2105) InternalName : version LegalCopyright : © Microsoft Corporation. All rights reserved. OriginalFilename : VERSION.DLL ProductName : Microsoft® Windows® Operating System ProductVersion : 5.1.2600.5512 Translation: 040904b0 The output looks similar to PE Explorer ($129 personal license). http://www.heaventools.com/img/scr-pex-dep-scanner.png It's also possible to compile the source of Showver, using winegcc on Mint (or other distros). The "unicode" mentioned three times here, plus adding the "extern C" to the source, solves the missing wmain problem (as other environments don't know what a wmain is). The "W" stands for the wide 16 bit characters used in the program. Your very first problem, will be finding the winegcc package. It actually uses mingw-w64 materials and there are a couple folders which have "wine" subfolders in /usr/lib. winegcc -municode -mno-cygwin -D_UNICODE -DUNICODE -o showver ShowVer.cpp -lversion -lstdc++ #include winver.h extern "C" // Add declaration before wmain wide main non-standard declaration int wmain() This produces two output files. showver.exe and showver.exe.so. The .so is a shared object, which doesn't contain a "wmain" main program. The .exe is actually a 699 byte text "script" to launch wine and process the ..so using wine. This totally defeats the purpose of using winegcc in the first place, which was to try to avoid the overhead of launching the entire wine ecosystem (which can take ten seconds the first time and is still slow even when all the files are in the read cache). https://i.postimg.cc/CLXX6sY1/showver-linux-wine.gif What "showver.exe" could get you though, is source code equivalent to "filever" Support Tools for WinXP package. You could, for example, put a "getnextfile" type tree traversal loop in the program, present a "top level directory" and walk down the tree, versioning everything in sight. This would mean only having the long wine launch overhead the one time, with the rest of the traversal being "at file system speed". You could process the entire C drive that way, if that's what you wanted to do. So that's my attempt to "paint within the lines". And not descend into byte-slinging. While byte-slinging is fun (writing the equivalent of version.dll your own self), and would have been something I would have done in the past, reusing code is a current approach of mine. The so-called "copy-paste" approach to code writing. In this case, it took an inordinately long time to track down this stuff. I think at peak, I had around 35 browser windows open, filled with semi-stupid ideas. Google didn't help at all. Inside the showver program, uses double-byte characters, to match what (as a Windows program) it would be getting from the NTFS file system for file names. However, in Linux-land, the shell uses unicode, and so there is some sort of translation (which I haven't tested thoroughly) going on when stdin and stdout are involved. I'm only mentioning that, to show that things aren't really as simple as they look (in terms of stuff breaking when you least expect it). And I still don't know if the above output is "all of it". I understand there's some "patching" information claimed to be present, which may not be part of the above approach. But since I don't know what I'm doing, this will have to remain a mystery :-) https://docs.microsoft.com/en-us/win...leversioninfoa "Remarks File version info has fixed and non-fixed part. The fixed part contains information like version number. The non-fixed part contains things like strings. In the past GetFileVersionInfo was taking version information from the binary (exe/dll). Currently, it is querying fixed version from language neutral file (exe/dll) and the non-fixed part from mui file, merges them and returns to the user. If the given binary does not have a mui file then behavior is as in previous version." That's really the crux of the problem, assembling a sufficient model to know what you're missing. Using the system library might cover off details of that sort. Paul |
Thread Tools | |
Display Modes | Rate This Thread |
|
|