How to enumerate all Version Information with Pointer to Version Information Block or another Pointe

[Kerem Gümrükcü]

Hi,

it is no big match to get the standard Version Information with
the known strings like "ProductName", "ProductVersion", etc, by
using GetFileVersionInfoSize(....), GetFileVersionInfo(...) and
VerQueryValue(...), but how do i get all the non-standard user-
defined strings without knowing their names. I mean is there
any way to enumerate them or place a "pattern/shape" on top
of the Memory-Block that i get e.g. with VerQueryValue(...) or
GetFileVersionInfo(...), because some People use their own information
like "BuildDate", "CompilerVersion","LicenseAgreement", etc., including
me! Explorer's Property Dialog shows them, so there must some way
for doing this,...i guess there must be some Pattern/LinkedList/Structure
to do this,...

Thanks for any help,...

Regards

Kerem

 

[Tim Roberts]

it is no big match to get the standard Version Information with
the known strings like "ProductName", "ProductVersion", etc, by
using GetFileVersionInfoSize(....), GetFileVersionInfo(...) and
VerQueryValue(...), but how do i get all the non-standard user-
defined strings without knowing their names. I mean is there
any way to enumerate them or place a "pattern/shape" on top
of the Memory-Block that i get e.g. with VerQueryValue(...) or
GetFileVersionInfo(...), because some People use their own information
like "BuildDate", "CompilerVersion","LicenseAgreement", etc., including
me! Explorer's Property Dialog shows them, so there must some way
for doing this,...i guess there must be some Pattern/LinkedList/Structure
to do this,...

The format is rather easy to reverse engineer. Have you dumped the buffer
you get from GetFileVersionInfo?

 

[Remy Lebeau]

how do i get all the non-standard user-defined strings without
knowing their names. I mean is there any way to enumerate them

You have to manually access them from the raw data that
GetFileVersionInfo/Ex() returns. There is no API function for enumerating
them. Have a look at the info on the following section of MSDN:

http://msdn.microsoft.com/en-us/library/dd458603(VS.85).aspx

For example, the following code loops through the available names in all
languages:

#include <pshpack1.h>
struct VerHdr
{
WORD wLength;
WORD wValueLength;
WORD wType;
WCHAR szKey[0];
};
#include <poppack.h>

#define PADOFFSETLEN(start, len) (LPBYTE(start) + ((DWORD(len) + 3) & ~3))
#define PADOFFSET(start, cur) PADOFFSETLEN(start, LPBYTE(cur) -
LPBYTE(start))

#pragma argsused
WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int nCmdShow)
{
TCHAR szFileName[MAX_PATH+1] = {0};
GetModuleFileName(NULL, szFileName, MAX_PATH);

DWORD dwHandle = 0;
DWORD dwLen = GetFileVersionInfoSize(szFileName, &dwHandle);
if( dwLen )
{
LPVOID pData = LocalAlloc(LMEM_FIXED, dwLen);
if( pData )
{
if( GetFileVersionInfo(szFileName, dwHandle, dwLen, pData) )
{
LPBYTE ptr = (LPBYTE) pData;

VerHdr *pVersionInfo = (VerHdr*) ptr; ptr += sizeof(VerHdr);
ptr += ((lstrlenW(pVersionInfo->szKey) + 1) * sizeof(WCHAR));
ptr = PADOFFSET(pVersionInfo, ptr);
ptr += pVersionInfo->wValueLength;
ptr = PADOFFSET(pVersionInfo, ptr);

LPBYTE pVersionInfoEnd = (LPBYTE(pVersionInfo) +
pVersionInfo->wLength);
while( ptr < pVersionInfoEnd )
{
VerHdr *pChildInfo = (VerHdr*) ptr; ptr += sizeof(VerHdr);
ptr += ((lstrlenW(pChildInfo->szKey) + 1) * sizeof(WCHAR));
ptr = PADOFFSET(pChildInfo, ptr);

if( lstrcmpiW(pChildInfo->szKey, L"StringFileInfo") == 0 )
{
LPBYTE pChildEnd = (LPBYTE(pChildInfo) + pChildInfo->wLength);
while( ptr < pChildEnd )
{
VerHdr *pStringTable = (VerHdr*) ptr; ptr += sizeof(VerHdr);
ptr += ((lstrlenW(pStringTable->szKey) + 1) * sizeof(WCHAR));
ptr = PADOFFSET(pStringTable, ptr);

MessageBoxW(NULL, pStringTable->szKey, L"Language", MB_OK);

LPBYTE pStringTableEnd = (LPBYTE(pStringTable) +
pStringTable->wLength);
while( ptr < pStringTableEnd )
{
VerHdr *pString = (VerHdr*) ptr;
ptr += sizeof(VerHdr);
ptr += ((lstrlenW(pString->szKey) + 1) * sizeof(WCHAR));
ptr = PADOFFSET(pString, ptr);
LPWSTR pValue = (LPWSTR) ptr;

MessageBoxW(NULL, pString->szKey, L"String Name", MB_OK);
MessageBoxW(NULL, pValue, L"String Value", MB_OK);

ptr = PADOFFSETLEN(pString, pString->wLength);
}

ptr = PADOFFSETLEN(pStringTable, pStringTable->wLength);
}
}

ptr = PADOFFSETLEN(pChildInfo, pChildInfo->wLength);
}

MessageBeep(0);
}
LocalFree(pData);
}
}
return 0;
}

 

[Remy Lebeau]

The format is rather easy to reverse engineer.

You don't have to reverse engineer it. The format is publically documented
in MSDN.

 

[Kerem Gümrükcü]

Hi,

thanks for all answers,...

Regards

Kerem

 

[Günter Prossliner]

Hello Kerem!

it is no big match to get the standard Version Information with
the known strings like "ProductName", "ProductVersion", etc, by
using GetFileVersionInfoSize(....), GetFileVersionInfo(...) and
VerQueryValue(...), but how do i get all the non-standard user-
defined strings without knowing their names. I mean is there
any way to enumerate them or place a "pattern/shape" on top
of the Memory-Block that i get e.g. with VerQueryValue(...) or
GetFileVersionInfo(...), because some People use their own information
like "BuildDate", "CompilerVersion","LicenseAgreement", etc.,
including me! Explorer's Property Dialog shows them, so there must
some way for doing this,...i guess there must be some
Pattern/LinkedList/Structure to do this,...

Be aware of the fact, that there is more than one implementation of this.

Basically:

1. PE File can provide this in an embeeded resource (this is what you get
from GetFileVersionInfo... functions)

2. If it's no PE-File, and the format supports metadata (like ID3 Tags or
EXIF or whatever), a shell-extension kicks in and provide these to windows
explorer (maybe readonly or even writable)

[Property Handlers]
http://msdn.microsoft.com/en-us/library/cc144131(VS.85).aspx

3. If it's no PE-File, and the format doesn't support metadata (like a .txt
file), explorer.exe still allows you to store metadata along with the file.
This is stored in a alternative NTFS Data Stream.


4. e.g. old Office formats may also use COM bound storage methods (is
related to #2), Office 2007 uses the new "Packaging" format (based on zip),
you can use System.IO.Packaging for that.


[Document Metadata Blog]
http://www.document-metadata.com/document-metadata-blog.html


Are you restricted to PE files, or do you want to read various formats?

If you are not limited to PE-Files maybe it would be an option to use the
Shell API to grap the same properties as explorer.exe.



GP

 

[Kerem Gümrükcü]

Hi Remy,

thanks for the great example! Now i have to
translate this to C#, the old game begins, since
the target application is a .NET application again,...

Regards

Kerem

--
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

how do i get all the non-standard user-defined strings without
knowing their names. I mean is there any way to enumerate them

You have to manually access them from the raw data that
GetFileVersionInfo/Ex() returns. There is no API function for enumerating
them. Have a look at the info on the following section of MSDN:

http://msdn.microsoft.com/en-us/library/dd458603(VS.85).aspx

For example, the following code loops through the available names in all
languages:

#include <pshpack1.h>
struct VerHdr
{
WORD wLength;
WORD wValueLength;
WORD wType;
WCHAR szKey[0];
};
#include <poppack.h>

#define PADOFFSETLEN(start, len) (LPBYTE(start) + ((DWORD(len) + 3) & ~3))
#define PADOFFSET(start, cur) PADOFFSETLEN(start, LPBYTE(cur) -
LPBYTE(start))

#pragma argsused
WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int nCmdShow)
{
TCHAR szFileName[MAX_PATH+1] = {0};
GetModuleFileName(NULL, szFileName, MAX_PATH);

DWORD dwHandle = 0;
DWORD dwLen = GetFileVersionInfoSize(szFileName, &dwHandle);
if( dwLen )
{
LPVOID pData = LocalAlloc(LMEM_FIXED, dwLen);
if( pData )
{
if( GetFileVersionInfo(szFileName, dwHandle, dwLen, pData) )
{
LPBYTE ptr = (LPBYTE) pData;

VerHdr *pVersionInfo = (VerHdr*) ptr; ptr += sizeof(VerHdr);
ptr += ((lstrlenW(pVersionInfo->szKey) + 1) * sizeof(WCHAR));
ptr = PADOFFSET(pVersionInfo, ptr);
ptr += pVersionInfo->wValueLength;
ptr = PADOFFSET(pVersionInfo, ptr);

LPBYTE pVersionInfoEnd = (LPBYTE(pVersionInfo) +
pVersionInfo->wLength);
while( ptr < pVersionInfoEnd )
{
VerHdr *pChildInfo = (VerHdr*) ptr; ptr += sizeof(VerHdr);
ptr += ((lstrlenW(pChildInfo->szKey) + 1) * sizeof(WCHAR));
ptr = PADOFFSET(pChildInfo, ptr);

if( lstrcmpiW(pChildInfo->szKey, L"StringFileInfo") == 0 )
{
LPBYTE pChildEnd = (LPBYTE(pChildInfo) + pChildInfo->wLength);
while( ptr < pChildEnd )
{
VerHdr *pStringTable = (VerHdr*) ptr; ptr += sizeof(VerHdr);
ptr += ((lstrlenW(pStringTable->szKey) + 1) * sizeof(WCHAR));
ptr = PADOFFSET(pStringTable, ptr);

MessageBoxW(NULL, pStringTable->szKey, L"Language", MB_OK);

LPBYTE pStringTableEnd = (LPBYTE(pStringTable) +
pStringTable->wLength);
while( ptr < pStringTableEnd )
{
VerHdr *pString = (VerHdr*) ptr;
ptr += sizeof(VerHdr);
ptr += ((lstrlenW(pString->szKey) + 1) * sizeof(WCHAR));
ptr = PADOFFSET(pString, ptr);
LPWSTR pValue = (LPWSTR) ptr;

MessageBoxW(NULL, pString->szKey, L"String Name", MB_OK);
MessageBoxW(NULL, pValue, L"String Value", MB_OK);

ptr = PADOFFSETLEN(pString, pString->wLength);
}

ptr = PADOFFSETLEN(pStringTable, pStringTable->wLength);
}
}

ptr = PADOFFSETLEN(pChildInfo, pChildInfo->wLength);
}

MessageBeep(0);
}
LocalFree(pData);
}
}
return 0;
}

 

[Tom Serface]

PJ's class is quite nice as well:

http://www.naughter.com/versioninfo.html

Tom

 

[Kerem Gümrükcü]

Hi Günther,

its only meant to read out compiled resources data
from PE files, there is no need for NTFS-AS, Shell Extemsions,
PropertyBags, etc,...PE-RES Data only,...


Regards

Kerem

--
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

Hello Kerem!

it is no big match to get the standard Version Information with
the known strings like "ProductName", "ProductVersion", etc, by
using GetFileVersionInfoSize(....), GetFileVersionInfo(...) and
VerQueryValue(...), but how do i get all the non-standard user-
defined strings without knowing their names. I mean is there
any way to enumerate them or place a "pattern/shape" on top
of the Memory-Block that i get e.g. with VerQueryValue(...) or
GetFileVersionInfo(...), because some People use their own information
like "BuildDate", "CompilerVersion","LicenseAgreement", etc.,
including me! Explorer's Property Dialog shows them, so there must
some way for doing this,...i guess there must be some
Pattern/LinkedList/Structure to do this,...

Be aware of the fact, that there is more than one implementation of this.

Basically:

1. PE File can provide this in an embeeded resource (this is what you get
from GetFileVersionInfo... functions)

2. If it's no PE-File, and the format supports metadata (like ID3 Tags or
EXIF or whatever), a shell-extension kicks in and provide these to windows
explorer (maybe readonly or even writable)

[Property Handlers]
http://msdn.microsoft.com/en-us/library/cc144131(VS.85).aspx

3. If it's no PE-File, and the format doesn't support metadata (like a
.txt file), explorer.exe still allows you to store metadata along with the
file. This is stored in a alternative NTFS Data Stream.


4. e.g. old Office formats may also use COM bound storage methods (is
related to #2), Office 2007 uses the new "Packaging" format (based on
zip), you can use System.IO.Packaging for that.


[Document Metadata Blog]
http://www.document-metadata.com/document-metadata-blog.html


Are you restricted to PE files, or do you want to read various formats?

If you are not limited to PE-Files maybe it would be an option to use the
Shell API to grap the same properties as explorer.exe.



GP

 

[Kerem Gümrükcü]

Hi Tom,

yes thats cool, but i need that all to translate to C#/Pinvoke.
My luck is, that i can work with unsafe PInvoke and can use
C-Like Ponter Code, so the Remy Example is quite good to
port over to C#/.NET basis,...

At first i will try to implement the code without unsafe
context and if it does not work as expected, ill go unsafe.
This will work always, since i can access data directy with
pointers. But i guess it will be possible to solve it without
unsafe stuff,..in the past i had really very little need to use
unsafe stuff in .NET Code with C#,...

Regards

Kerem

 

[nico]

There is no API function for enumerating them.

Yes, there is one, for non-vista OS (see Win32 group)

 

[Victor]

Well, could you provide a link to the thread discussing/mentioning this API,
or, at least, provide some words to search for?

Victor

 

[Kerem Gümrükcü]

Hi Victor,

i asked the same question on the Win32 NG here:

http://groups.google.com/group/comp...ad/644148b73b254c3e/b467f1804ac18fd6?lnk=raot

But the API is only available to Versions prior Vista,...thats sad,...

Regards

Kerem

 

[Remy Lebeau]

i asked the same question on the Win32 NG here:

http://groups.google.com/group/comp...ad/644148b73b254c3e/b467f1804ac18fd6?lnk=raot

But the API is only available to Versions prior Vista,...thats sad,...

The VerQueryValueIndex() function was never documented by Microsoft. Most
people did not even know it existed (you can't even find it in online
searches anywhere), and so they would not miss it when Microsoft removed it
in Vista. It should be pretty simple to emulate it in user code, though.

 

[Kerem Gümrükcü]

Hi Remy,

yes, you are right, never documented and never published.
I did also did a intense google search and ReactOS API
lookup, but really nothing documented,....

Can i send you a sample i wrote in C# (Library) and
Frontend in VB.NET,....so you can see, what i did so far,...

Regards

Kerem

 

[Volodymyr Shcherbyna]

So if you are going to read only resources from PE files be ready to test
your code on x64 binaries as well, as the structures are different
(different size). Good luck

--
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)

Hi Günther,

its only meant to read out compiled resources data
from PE files, there is no need for NTFS-AS, Shell Extemsions,
PropertyBags, etc,...PE-RES Data only,...


Regards

Kerem

--
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

Hello Kerem!

it is no big match to get the standard Version Information with
the known strings like "ProductName", "ProductVersion", etc, by
using GetFileVersionInfoSize(....), GetFileVersionInfo(...) and
VerQueryValue(...), but how do i get all the non-standard user-
defined strings without knowing their names. I mean is there
any way to enumerate them or place a "pattern/shape" on top
of the Memory-Block that i get e.g. with VerQueryValue(...) or
GetFileVersionInfo(...), because some People use their own information
like "BuildDate", "CompilerVersion","LicenseAgreement", etc.,
including me! Explorer's Property Dialog shows them, so there must
some way for doing this,...i guess there must be some
Pattern/LinkedList/Structure to do this,...

Be aware of the fact, that there is more than one implementation of this.

Basically:

1. PE File can provide this in an embeeded resource (this is what you get
from GetFileVersionInfo... functions)

2. If it's no PE-File, and the format supports metadata (like ID3 Tags or
EXIF or whatever), a shell-extension kicks in and provide these to
windows explorer (maybe readonly or even writable)

[Property Handlers]
http://msdn.microsoft.com/en-us/library/cc144131(VS.85).aspx

3. If it's no PE-File, and the format doesn't support metadata (like a
.txt file), explorer.exe still allows you to store metadata along with
the file. This is stored in a alternative NTFS Data Stream.


4. e.g. old Office formats may also use COM bound storage methods (is
related to #2), Office 2007 uses the new "Packaging" format (based on
zip), you can use System.IO.Packaging for that.


[Document Metadata Blog]
http://www.document-metadata.com/document-metadata-blog.html


Are you restricted to PE files, or do you want to read various formats?

If you are not limited to PE-Files maybe it would be an option to use the
Shell API to grap the same properties as explorer.exe.



GP

 

[Kerem Gümrükcü]

Hi Volodymyr,

thanks for your reply, but the problem is
not anymore. The last Months i am doing
lots of C# and the good part is as long as you
work strictly with .NET Datatypes you will have
no problem with sizes. You do a single build,
its a so called architecture independent assembly
and it works on 32 and 64 as well. Sure you have
to declare and map the structures and code from
native code very carefully,...but i did it now,...and it
works just fine, no border and boundary violation
and memory corruption so far,...;-)

Have nice day,...

Regards

Kerem

--
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

So if you are going to read only resources from PE files be ready to test
your code on x64 binaries as well, as the structures are different
(different size). Good luck

--
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)

Hi Günther,

its only meant to read out compiled resources data
from PE files, there is no need for NTFS-AS, Shell Extemsions,
PropertyBags, etc,...PE-RES Data only,...


Regards

Kerem

--
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

Hello Kerem!

it is no big match to get the standard Version Information with
the known strings like "ProductName", "ProductVersion", etc, by
using GetFileVersionInfoSize(....), GetFileVersionInfo(...) and
VerQueryValue(...), but how do i get all the non-standard user-
defined strings without knowing their names. I mean is there
any way to enumerate them or place a "pattern/shape" on top
of the Memory-Block that i get e.g. with VerQueryValue(...) or
GetFileVersionInfo(...), because some People use their own information
like "BuildDate", "CompilerVersion","LicenseAgreement", etc.,
including me! Explorer's Property Dialog shows them, so there must
some way for doing this,...i guess there must be some
Pattern/LinkedList/Structure to do this,...

Be aware of the fact, that there is more than one implementation of
this.

Basically:

1. PE File can provide this in an embeeded resource (this is what you
get from GetFileVersionInfo... functions)

2. If it's no PE-File, and the format supports metadata (like ID3 Tags
or EXIF or whatever), a shell-extension kicks in and provide these to
windows explorer (maybe readonly or even writable)

[Property Handlers]
http://msdn.microsoft.com/en-us/library/cc144131(VS.85).aspx

3. If it's no PE-File, and the format doesn't support metadata (like a
.txt file), explorer.exe still allows you to store metadata along with
the file. This is stored in a alternative NTFS Data Stream.


4. e.g. old Office formats may also use COM bound storage methods (is
related to #2), Office 2007 uses the new "Packaging" format (based on
zip), you can use System.IO.Packaging for that.


[Document Metadata Blog]
http://www.document-metadata.com/document-metadata-blog.html


Are you restricted to PE files, or do you want to read various formats?

If you are not limited to PE-Files maybe it would be an option to use
the Shell API to grap the same properties as explorer.exe.



GP

 

[Volodymyr Shcherbyna]

In x64 Windows you might have x32 binaries running via WoW, so your x64
application might encounter a case when 32bit application resources has to
be analyzed. Since you complied your application under x64, the structure
IMAGE_NT_HEADERS will be actually the IMAGE_NT_HEADERS64 while you still
need to use IMAGE_NT_HEADERS32 to read from x32 application.

Ideally you should be ready to handle both types of executables in x64
Windows. So, you have explicitly declare IMAGE_NT_HEADERS32 and
IMAGE_NT_HEADERS64 and use them depending on IMAGE_FILE_HEADER->Machine
member in executable.

Good luck,

--
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)

Hi Volodymyr,

thanks for your reply, but the problem is
not anymore. The last Months i am doing
lots of C# and the good part is as long as you
work strictly with .NET Datatypes you will have
no problem with sizes. You do a single build,
its a so called architecture independent assembly
and it works on 32 and 64 as well. Sure you have
to declare and map the structures and code from
native code very carefully,...but i did it now,...and it
works just fine, no border and boundary violation
and memory corruption so far,...;-)

Have nice day,...

Regards

Kerem

--
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

So if you are going to read only resources from PE files be ready to test
your code on x64 binaries as well, as the structures are different
(different size). Good luck

--
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)

Hi Günther,

its only meant to read out compiled resources data
from PE files, there is no need for NTFS-AS, Shell Extemsions,
PropertyBags, etc,...PE-RES Data only,...


Regards

Kerem

--
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

Hello Kerem!

it is no big match to get the standard Version Information with
the known strings like "ProductName", "ProductVersion", etc, by
using GetFileVersionInfoSize(....), GetFileVersionInfo(...) and
VerQueryValue(...), but how do i get all the non-standard user-
defined strings without knowing their names. I mean is there
any way to enumerate them or place a "pattern/shape" on top
of the Memory-Block that i get e.g. with VerQueryValue(...) or
GetFileVersionInfo(...), because some People use their own information
like "BuildDate", "CompilerVersion","LicenseAgreement", etc.,
including me! Explorer's Property Dialog shows them, so there must
some way for doing this,...i guess there must be some
Pattern/LinkedList/Structure to do this,...

Be aware of the fact, that there is more than one implementation of
this.

Basically:

1. PE File can provide this in an embeeded resource (this is what you
get from GetFileVersionInfo... functions)

2. If it's no PE-File, and the format supports metadata (like ID3 Tags
or EXIF or whatever), a shell-extension kicks in and provide these to
windows explorer (maybe readonly or even writable)

[Property Handlers]
http://msdn.microsoft.com/en-us/library/cc144131(VS.85).aspx

3. If it's no PE-File, and the format doesn't support metadata (like a
.txt file), explorer.exe still allows you to store metadata along with
the file. This is stored in a alternative NTFS Data Stream.


4. e.g. old Office formats may also use COM bound storage methods (is
related to #2), Office 2007 uses the new "Packaging" format (based on
zip), you can use System.IO.Packaging for that.


[Document Metadata Blog]
http://www.document-metadata.com/document-metadata-blog.html


Are you restricted to PE files, or do you want to read various formats?

If you are not limited to PE-Files maybe it would be an option to use
the Shell API to grap the same properties as explorer.exe.



GP

 

[Volodymyr Shcherbyna]

Ah, I looked at example posted to you, it is using GetFileVersionInfo(...)
so my above comments do not apply. Sorry.

--
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)

In x64 Windows you might have x32 binaries running via WoW, so your x64
application might encounter a case when 32bit application resources has to
be analyzed. Since you complied your application under x64, the structure
IMAGE_NT_HEADERS will be actually the IMAGE_NT_HEADERS64 while you still
need to use IMAGE_NT_HEADERS32 to read from x32 application.

Ideally you should be ready to handle both types of executables in x64
Windows. So, you have explicitly declare IMAGE_NT_HEADERS32 and
IMAGE_NT_HEADERS64 and use them depending on IMAGE_FILE_HEADER->Machine
member in executable.

Good luck,

--
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)

Hi Volodymyr,

thanks for your reply, but the problem is
not anymore. The last Months i am doing
lots of C# and the good part is as long as you
work strictly with .NET Datatypes you will have
no problem with sizes. You do a single build,
its a so called architecture independent assembly
and it works on 32 and 64 as well. Sure you have
to declare and map the structures and code from
native code very carefully,...but i did it now,...and it
works just fine, no border and boundary violation
and memory corruption so far,...;-)

Have nice day,...

Regards

Kerem

--
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

So if you are going to read only resources from PE files be ready to
test your code on x64 binaries as well, as the structures are different
(different size). Good luck

--
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)

Hi Günther,

its only meant to read out compiled resources data
from PE files, there is no need for NTFS-AS, Shell Extemsions,
PropertyBags, etc,...PE-RES Data only,...


Regards

Kerem

--
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

Hello Kerem!

it is no big match to get the standard Version Information with
the known strings like "ProductName", "ProductVersion", etc, by
using GetFileVersionInfoSize(....), GetFileVersionInfo(...) and
VerQueryValue(...), but how do i get all the non-standard user-
defined strings without knowing their names. I mean is there
any way to enumerate them or place a "pattern/shape" on top
of the Memory-Block that i get e.g. with VerQueryValue(...) or
GetFileVersionInfo(...), because some People use their own
information
like "BuildDate", "CompilerVersion","LicenseAgreement", etc.,
including me! Explorer's Property Dialog shows them, so there must
some way for doing this,...i guess there must be some
Pattern/LinkedList/Structure to do this,...

Be aware of the fact, that there is more than one implementation of
this.

Basically:

1. PE File can provide this in an embeeded resource (this is what you
get from GetFileVersionInfo... functions)

2. If it's no PE-File, and the format supports metadata (like ID3 Tags
or EXIF or whatever), a shell-extension kicks in and provide these to
windows explorer (maybe readonly or even writable)

[Property Handlers]
http://msdn.microsoft.com/en-us/library/cc144131(VS.85).aspx

3. If it's no PE-File, and the format doesn't support metadata (like a
.txt file), explorer.exe still allows you to store metadata along with
the file. This is stored in a alternative NTFS Data Stream.


4. e.g. old Office formats may also use COM bound storage methods (is
related to #2), Office 2007 uses the new "Packaging" format (based on
zip), you can use System.IO.Packaging for that.


[Document Metadata Blog]
http://www.document-metadata.com/document-metadata-blog.html


Are you restricted to PE files, or do you want to read various
formats?

If you are not limited to PE-Files maybe it would be an option to use
the Shell API to grap the same properties as explorer.exe.



GP

 

[Kerem Gümrükcü]

Hi Volodymyr,

thanks for your reply. I now use the LoadImage(...)
to get the Icons and Bitmaps i needed to work with.
Anyway thank you very much for your effort,...

Regards

K.

--
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

Ah, I looked at example posted to you, it is using GetFileVersionInfo(...)
so my above comments do not apply. Sorry.

--
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)

In x64 Windows you might have x32 binaries running via WoW, so your x64
application might encounter a case when 32bit application resources has
to be analyzed. Since you complied your application under x64, the
structure IMAGE_NT_HEADERS will be actually the IMAGE_NT_HEADERS64 while
you still need to use IMAGE_NT_HEADERS32 to read from x32 application.

Ideally you should be ready to handle both types of executables in x64
Windows. So, you have explicitly declare IMAGE_NT_HEADERS32 and
IMAGE_NT_HEADERS64 and use them depending on IMAGE_FILE_HEADER->Machine
member in executable.

Good luck,

--
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)

Hi Volodymyr,

thanks for your reply, but the problem is
not anymore. The last Months i am doing
lots of C# and the good part is as long as you
work strictly with .NET Datatypes you will have
no problem with sizes. You do a single build,
its a so called architecture independent assembly
and it works on 32 and 64 as well. Sure you have
to declare and map the structures and code from
native code very carefully,...but i did it now,...and it
works just fine, no border and boundary violation
and memory corruption so far,...;-)

Have nice day,...

Regards

Kerem

--
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

Newsbeitrag So if you are going to read only resources from PE files be ready to
test your code on x64 binaries as well, as the structures are different
(different size). Good luck

--
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)

Hi Günther,

its only meant to read out compiled resources data
from PE files, there is no need for NTFS-AS, Shell Extemsions,
PropertyBags, etc,...PE-RES Data only,...


Regards

Kerem

--
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

Hello Kerem!

it is no big match to get the standard Version Information with
the known strings like "ProductName", "ProductVersion", etc, by
using GetFileVersionInfoSize(....), GetFileVersionInfo(...) and
VerQueryValue(...), but how do i get all the non-standard user-
defined strings without knowing their names. I mean is there
any way to enumerate them or place a "pattern/shape" on top
of the Memory-Block that i get e.g. with VerQueryValue(...) or
GetFileVersionInfo(...), because some People use their own
information
like "BuildDate", "CompilerVersion","LicenseAgreement", etc.,
including me! Explorer's Property Dialog shows them, so there must
some way for doing this,...i guess there must be some
Pattern/LinkedList/Structure to do this,...

Be aware of the fact, that there is more than one implementation of
this.

Basically:

1. PE File can provide this in an embeeded resource (this is what you
get from GetFileVersionInfo... functions)

2. If it's no PE-File, and the format supports metadata (like ID3
Tags or EXIF or whatever), a shell-extension kicks in and provide
these to windows explorer (maybe readonly or even writable)

[Property Handlers]
http://msdn.microsoft.com/en-us/library/cc144131(VS.85).aspx

3. If it's no PE-File, and the format doesn't support metadata (like
a .txt file), explorer.exe still allows you to store metadata along
with the file. This is stored in a alternative NTFS Data Stream.


4. e.g. old Office formats may also use COM bound storage methods (is
related to #2), Office 2007 uses the new "Packaging" format (based on
zip), you can use System.IO.Packaging for that.


[Document Metadata Blog]
http://www.document-metadata.com/document-metadata-blog.html


Are you restricted to PE files, or do you want to read various
formats?

If you are not limited to PE-Files maybe it would be an option to use
the Shell API to grap the same properties as explorer.exe.



GP