Versionsinfo auslesen ohne \VarFileInfo\Translation

[moelski]

Moin !

s.h.a.r.k hat in diesem Beitrag ...
http://www.delphipraxis.net/internal...sfixedfileinfo
eine nette Klasse gepostet -> classTExeInformation.

Der Grundlegende Code zu der Klasse scheint übrigens (nebenbei erwähnt) von hier zu stammen:
http://www.swissdelphicenter.ch/torr...de.php?id=1047

Die funzt auch ganz prächtig bis auf 2 Kleinigkeiten...

1) So wie die Klasse ist kann man nur EXE Dateien damit abfragen. Bei DLL / SYS streikt die Klasse und das liegt wohl an dem Teil hier:

Delphi-Quellcode:

    iRet := SHGetFileInfo(PChar(FExeFilename), 0, rSHFI, SizeOf(rSHFI), SHGFI_EXETYPE);
    if iRet <> 0 then
    ...

Wenn ich den Teil weglasse, dann kann ich die Klasse auch für DLL / SYS verwenden. Frage ... Stellt das ein nennenswertes Problem dar? Oder ist das letztlich nur noch eine Zusatzüberprüfung ob die Datei wirklich eine Executable ist?

2) Und das ist die eigentlich wichtigerere Frage ... Wenn ich eine Datei habe in der kein '\VarFileInfo\Translation' Eintrag vorhanden ist, dann kann die Klasse keine Sprache ermitteln und daraus resultiert das keine Ergebnisse geliefert werden. Schaut man sich aber die Datei z.B. im Resource Tuner an, dann findet der sehrwohl Sprache als auch die Einträge wie Version, CompanyName, etc.
Wenn man den Code zum Auslesen der Infos dann hart auf die Sprache einstellt, dann kann man die auch ohne weitere lesen.
Kurzum, hat jemand eine Idee wie man die Klasse dahingehend erweitert, dass man auch ohne \VarFileInfo\Translation die Informationen aus der DLL lesen kann?

Ich hänge mal die Klasse an (ich hoffe Shark hat nix dagegen) und füge auch die DLL ein wie mir das mit dem fehlenden \VarFileInfo\Translation aufgefallen ist. Die DLL stammt vom IrfanView Projekt.

[s.h.a.r.k]

Vielleicht hilft es ja später nochmal einem. Hab mich wieder mal mit meiner Klasse beschäftigt und eine aktualisierte Version hochgeladen. Allerdings arbeitet diese immer noch mit dem Code der hier verlinkten Klasse, daher gibts immer noch Probleme.

Hier mal zwei Links, die helfen sollten Versionsinformationen aus Dateien auszulesen, die nicht nach dem MS-Standard gespeichert wurden.
http://www.delphidabbler.com/articles?article=20
http://www.delphidabbler.com/software/vibindata/main

[Bummi]

wenn Du nur die Version brauchst

Delphi-Quellcode:

Function GetFileVer(s:String):String;
type
zz=^VS_FIXEDFILEINFO;
var
p:Array[0..255] of Char;
poi:Pointer;
plen:Cardinal;
i,j:Integer;
begin
if GetFileVersionInfo(Pchar(s),0,SizeOf(p),@p[0]) then
   begin
   Result:=p;
   if VerQueryValue(@p[0],'\',poi,plen) then
   begin
   i:=VS_FIXEDFILEINFO(zz(poi)^).dwFileVersionMS;
   j:=VS_FIXEDFILEINFO(zz(poi)^).dwFileVersionLS;
   Result:=IntToStr(i div 65536)+'.'+IntToStr(i mod 65536)+'.'+IntToStr(j div 65536)+'.'+IntToStr(j mod 65536);
   end
   else Result:='';
   end
 else Result:='';
end;

[s.h.a.r.k]

So wie es aussieht, bezieht sich dein Code auch auf den MS-Standard für Versionsinformationen in einer Datei. Dies muss teilweise nicht gegeben sein, wodurch dein Code evtl. scheitern kann. Und genau hier kann man seinen "alten" quasi wegwerfen und die DLL von DelphiDabller nutzen :)

Für mich reicht meine bisherige Klasse, da ich lediglich die Version etc. aus meiner eigenen EXE auslese, somit dürfte dein Code auch für eigene Projekte wunderbar funktionieren. Will man aber unter umständen andere Files untersuchen, wirst du evtl. Probleme bekommen bzw. eben keinerlei Daten bekommen.

[himitsu]

http://www.delphipraxis.net/154099-v...fileutils.html
http://www.delphipraxis.net/142192-b...ompiliert.html
und ich bin mir relativ ganz sicher, daß in der DP-CodeLib auch was drinsteht.

[s.h.a.r.k]

Jo, aber die Codes nutzen alle die Windows-API. Mit Hilfe des MSDN kann man sich sogar selbst den Code mal schnell zusammen schreiben. Aber man stößt eben immer wieder an das Problem, dass es eben auch andere Formate gibt, die die Windows API nicht auslesen kann.

[himitsu]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1064937)

Aber man stößt eben immer wieder an das Problem, dass es eben auch andere Formate gibt, die die Windows API nicht auslesen kann.

Es gibt von MS entsprechende Spezifikationen, wie diese Resorce auszusehn hat und entsprechend dieser Vorgaben arbeitet auch die WinAPI.

Wenn jemand diese Resource anders/"falsch" erstellt, dann hat er eben Pech und es wird nichts angezeigt.