A Windows XP help forum. PCbanter

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.

Go Back   Home » PCbanter forum » Windows 10 » Windows 10 Help Forum
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

filever?



 
 
Thread Tools Rate Thread Display Modes
  #76  
Old February 4th 19, 03:30 PM posted to alt.comp.os.windows-10
Carlos E.R.[_3_]
external usenet poster
 
Posts: 1,356
Default 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  
Old February 4th 19, 03:37 PM posted to alt.comp.os.windows-10
Mayayana
external usenet poster
 
Posts: 6,438
Default 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  
Old February 4th 19, 03:42 PM posted to alt.comp.os.windows-10
Carlos E.R.[_3_]
external usenet poster
 
Posts: 1,356
Default 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  
Old February 4th 19, 03:44 PM posted to alt.comp.os.windows-10
Mayayana
external usenet poster
 
Posts: 6,438
Default 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  
Old February 4th 19, 05:28 PM posted to alt.comp.os.windows-10
Mayayana
external usenet poster
 
Posts: 6,438
Default 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  
Old February 10th 19, 10:06 AM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default 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
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off






All times are GMT +1. The time now is 12:07 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 PCbanter.
The comments are property of their posters.