Standort Comand Line Compiler (DCC32.exe) ermitteln

[Harry Stahl]

Bin gerade dabei, mein Editor-Programm in der Art zu erweitern, dass es ganze Delphi-Projekte einlesen und Source- und DFM-Formulare anzeigen kann.

Das brauche ich, weil ich hin und wieder etwas in einem älteren Projekt nachsehen möchte, wie ich etwas gemacht habe. Mitunter weiß ich aber nicht, mit welcher Delphi-Version ich das Projekt zuletzt erstellt habe.

Um nun zu vermeiden, dass Delphi mich nervt, weil ich mit einer falschen Delphi-Version das Projekt öffne oder Komponenten fehlen usw., kann ich die Projekte nun mit meinem Programm öffnen (siehe anliegenden Screenshot) und es erkennt zumindest alle Versionen von Delphi 5 bis Delphi 10 Seattle korrekt.

Hin und wieder existiert die dazugehörige Exe-Datei nicht mehr, entweder weil ich mal aufgeräumt habe oder z.B. hier ein Demo-Projekt aus der DP herunterlade, wo die EXE oft fehlt.

Wenn ich das Projekt schon einmal mit meinem Editor-Programm geladen habe, würde ich es auch ganz gerne kurz kompilieren, ohne dafür nach Delphi wechseln zu müssen.

Das sollte ich ja per Einbindung des Kommando-Zeilen Compilers von Delphi machen können (DCC32.EXE).

Nur wie finde ich den Standort der DCC32.EXE heraus? Zwar sind mit die Standard-Verzeichnisse von Delphi durchaus bekannt, aber ein anderer Anwender könnte ein Delphi ja mal in einem anderen Verzeichnis installiert haben.

Daher meine Frage: Gibt es irgendeinen Registry-Eintrag, wo ich entweder den Standort der (JEWEILIGEN) DCC32.exe rauslesen kann oder das BIN-Verzeichnis, wo ja die DCC32.exe drin sein müsste?

Könnte mir vorstellen, dass es wegen Wechsel über Borland, CodeGear, Emba verschiedene Einträge gibt? Kennt jemand eine entsprechende Übersicht / Info hierzu. Habe natürlich gegoogelt und hier in der DP gesucht, aber dazu nichts richtiges gefunden.

Edit: In dem Zusammenhang noch eine Frage: Gibt es eine Option, dass der Compiler nach erfolgreicher Kompilierung das Programm direkt startet?

[Sir Rufo]

https://theroadtodelphi.wordpress.co...lphi-versions/ sollte helfen

[Harry Stahl]

Super, ganz herzlichen Dank:thumb::thumb::thumb:

Genau das habe ich gesucht.

[Harry Stahl]

Na sagen wir mal: fast.

Ein "C:\D5\Borland" Installationsverzeichnis für Delphi 5 wird nicht gefunden.

Eigentlich seltsam,

die Funktion

Delphi-Quellcode:

function RegReadStr(const RegPath, RegValue:string; var Str: string;const RootKey :HKEY): Boolean;
var
  Reg: TRegistry;
begin
  try
    Reg := TRegistry.Create;
    try
      Reg.RootKey := RootKey;
      Result := Reg.OpenKey(RegPath, True);
      if Result then  Str:=Reg.ReadString(RegValue);
    finally
      Reg.Free;
    end;
  except
    Result := False;
  end;
end;

liefert für Result=Reg.Openkey ('\Software\Borland\Delphi\5.0')

zwar True zurück, aber beim

Reg.Readstring (RegValue ='App')

ist der Inhalt leer (obwohl in der Registry "C:\D5\Borland\Delphi5\Bin\Delphi32.exe" drin ist).

[jaenicke]

Hier gibt es von mir auch ein Projekt, das die dcc32.exe entsprechend aufruft:
http://www.entwickler-ecke.de/topic_...+20_41748.html
Wenn man diese benutzt, muss man ja auch die Pfade der entsprechenden Delphiversion übergeben usw., zudem wollte ich die farbliche Kennzeichnung in der Konsole.

Ich würde allerdings heute eher MSBuild verwenden, das das alles übernimmt. Oder meintest du das?

[Harry Stahl]

Gibt es noch einen anderen Download-Link? Habe bei der Entwickler-Ecke keinen Account.

[jaenicke]

Bisher für dieses Projekt nicht, daher:
Anhang 44895

[Harry Stahl]

Erst mal Danke.

Du verwendest hier

function TCompileProcess.GetDelphiRootPath(const ADelphiVersion: string): string;

welche im Prinzip der Funktion entspricht, auf die Sir Rufo mich hingwiesen hat.

Auch die hier findet daher den Delphi 5 Standort nicht (der hier in "C:\D5\Borland\Delphi5\Bin" ist, was ich nach wie vor nicht verstehe.

Mein Windows 8.1 hier ist ein 64-Bit-System, aber die Umlenkung auf den WOW6432Node erfolgt doch normalerweise automatisch, oder?

Tatsächlich steht der Eintrag ja in "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Borland\D elphi\5.0".

[jaenicke]

Hmm, komisch, hier funktioniert es. Genau dieser Zweig wird hier korrekt ausgelesen.

Schau doch einfach einmal mit dem Process Monitor.

[Harry Stahl]

Was genau sollte ich da schauen?

[Harry Stahl]

Wenn ich das Programm im Admin-Modus ausführe, dann wird der Pfad gelesen.

Warum ist das jetzt für diese einfache Ausleseaktion erforderlich?

[Dalai]

Schau dir die Berechtigungen des Registry-Zweigs an, dann weißt du, ob's daran liegt.

MfG Dalai

[Harry Stahl]

Bei Zugriffen auf HKEY_Local_Machine muss man anscheindend nach diesem Thread hier, den Wow6432Node selber ergänzen, damit es funktioniert.

Habe ich nun mal so gemacht, funktioniert trotzdem nicht:

Delphi-Quellcode:

function RegReadStr(RegPath, RegValue:string; var Str: string;const RootKey :HKEY): Boolean;
var
  Reg: TRegistry;
begin
  try
    Reg := TRegistry.Create;
    try
      Reg.RootKey := RootKey;

      if IsWindows64 then begin
        RegPath := ReplaceStr (RegPath, 'SOFTWARE\', 'SOFTWARE\Wow6432Node\', false);
      end;

      Result := Reg.OpenKey(RegPath, false);
      if Result then  Str:=Reg.ReadString(RegValue);
    finally
      Reg.Free;
    end;
  except
    Result := False;
  end;
end;

Openkey liefert schon false zurück

[Harry Stahl]

OK, des Rätsels Lösung: Die Laufzeit-Themes waren aktiviert, wenn ich die ausschalte, funktioniert es mit und ohne meine Ergänzung.

War mir nicht klar, dass die Standard-Laufzeit-Themes (hier gerade unter XE7) so eine Auswirkung haben (normalerweise habe ich immer meine eigene Manifest-Datei, aber bei diesem Projekt noch nicht).

[jaenicke]

Vermutlich gibt das Manifest eine andere Windowsversion als die Version an bis zu der die Anwendung kompatibel ist.
Dadurch wird wohl aus Kompatibilitätsgründen etwas umgeleitet.

Hast du mal statt OpenKey OpenKeyReadOnly ausprobiert?

[himitsu]

Das D5-Setup ist 32 Bit, drum steht das auch in WOW32.
Liest man das mit einem 32 Bit Programm aus dem "normalen" Pfad, dann wird man dahin umgeleitet.

Man kann beim Zugriff auf die Registry aber auch angeben, ob man diese Umleitung deaktiviert haben möchte.


Steht das BIN-Verteichnis des zuletzt installierten Delphi nicht vorne in PATH?
Dann kann man einfach nur "dcc32.exe" aufrufen und landet immer beim Letzten.

[Dalai]

Entweder

Delphi-Quellcode:

TRegistry.Create(KEY_READ)

benutzen oder

Delphi-Quellcode:

TRegistry.OpenKeyReadOnly

, um lediglich lesend auf den Zweig zuzugreifen. TRegistry.Open öffnet standardmäßig schreibend, was ohne Adminrechte nunmal nicht geht.

Eine Ersetzung/Benutzung von 'Wow6432Node' ist eine ganz schlechte Idee, denn einerseits braucht man das ausschließlich dann, wenn ein 64 Bit Programm auf den 32 Bit Zweig zugreifen will und andererseits rät MS davon ab, den String hartkodiert zu benutzen. Stattdessen gibt es Flags, die man beim Öffnen eines Schlüssel - bei Delphi im Konstruktur TRegistry.Create - benutzen kann: KEY_WOW64_64KEY und KEY_WOW64_32KEY.

Will sagen: Es gibt überhaupt keinen Grund, das Manifest rauszunehmen.

MfG Dalai

[Harry Stahl]

Und die beiden Keys nutze ich wie, in welcher Konstellation?

Also angenommen, ich habe ein 32-Bit-Programm.

Nutze ich dann einen der beiden Schlüssel?

[Harry Stahl]

Jedenfalls, funktioniert es jetzt soweit ohne Manifest, werde morgen mal ein aktuelles einbinden und dann mal sehen.

Hinweis @ Jaenicke: In Deinem Programm wurde Delphi 5 nicht gefunden, weil der Eintrag nicht unter current_user zu finden war, sondern unter local_machine.

Dein Programm müsste man also so erweitern, dass es den Pfad auch unter diesen Bedingungen findet:

Delphi-Quellcode:

function TCompileProcess.GetDelphiRootPath(const ADelphiVersion: string): string;
var
  Reg: TRegistry;
begin
  Result := '';
  if FRegistryPath = '' then
    FRegistryPath := GetRegistryPath(ADelphiVersion, True);
  Reg := TRegistry.Create(KEY_READ);
  try
    Reg.RootKey := HKEY_CURRENT_USER;
    if Reg.OpenKeyReadOnly(FRegistryPath) then
    begin
      Result := ExtractFilePath(Reg.ReadString('App'));
      Reg.CloseKey();
    end;

    if Result = '' then // neu hier
    begin
      Reg.RootKey := HKEY_LOCAL_MACHINE;
      if Reg.OpenKeyReadOnly(FRegistryPath) then
      begin
        Result := ExtractFilePath(Reg.ReadString('App'));
        Reg.CloseKey();
      end;
    end;

  finally
    Reg.Free();
  end;
end;

Übrigens compiliert das Programm bei Deiner Lösung nicht, weil es offensichtlich eine Reihe von Pfadangaben auflöst. Allerdings stimmen davon einige nicht mehr und dann bricht der Compiler ab.

Ich verwende daher nur den reinen Compileraufruf, seltsamerweise compiliert er, obwohl 2 Units in anderen Verzeichnissen stehen (die könnte der Compiler aber auflösen, aus den Angaben der Projektdatei (dpr)).

Dank Deines Beispiels habe ich gesehen, wie man den output des Compilers (das in Deinem Programm ja in ein Konsolenfenster geht) abfangen kann. Habe ich bei mir so gelöst, dass ich das in meinem Programm in ein Memo ausgebe.

Der Output erscheint mir aber etwas seltsam (siehe anliegenden Screenschot unten).

[jaenicke]

Die Ausgabe des Compilers ist völlig in Ordnung. Wenn du die Ausgabe haben möchtest, die du in der Delphi IDE siehst, dann musst du MSBuild benutzen.

[HolgerX]

Hmm..

Da ich überwiegend 32bit Tools erstelle habe ich immer die Probleme auf einem 64bit Windows Systemeinstellungen auslesen zu können.

Deshalb habe ich mir hier ein Hilfskonstrukt zusammengebastelt:

Delphi-Quellcode:

const
  KEY_WOW64_64KEY = $0100;
  KEY_WOW64_32KEY = $0200;


function IsWow64A: Boolean;
type
  TIsWow64Process = function( // Type of IsWow64Process API fn
    Handle: Windows.THandle; var Res: Windows.BOOL ): Windows.BOOL; stdcall;
var
  IsWow64Result: Windows.BOOL; // Result from IsWow64Process
  IsWow64Process: TIsWow64Process; // IsWow64Process fn reference
begin
  // Try to load required function from kernel32
  IsWow64Process := Windows.GetProcAddress(Windows.GetModuleHandle('kernel32'), 'IsWow64Process');

  if Assigned(IsWow64Process) then begin
    // Function is implemented: call it
    if not IsWow64Process(Windows.GetCurrentProcess, IsWow64Result) then
      raise Exception.Create('IsWow64: bad process handle');

    Result := IsWow64Result; // Return result of function
  end else
    // Function not implemented: can't be running on Wow64
    Result := False;
end;







  if IsWow64A then
    Reg := TRegistry.Create(KEY_READ or KEY_WOW64_64KEY)
  else
    Reg := TRegistry.Create(KEY_READ);
  try
    Reg.RootKey := HKEY_LOCAL_MACHINE;
    if Reg.OpenKey('\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon', False) then begin
      try
..
      finally
        Reg.CloseKey;
      end;
    end;
  finally
    Reg.Free;
  end;

Wenn ich als 32bit Prozess unter 64bit OS aus der Registry lesen/schreiben will und zwar aus dem NICHT Wow64.. dann brauche ich KEY_WOW64_64KEY.

Umgekehrt kann ein 64bit Programm die Konfigurationen aus einem wow64-Zweig auslesen, indem explizit KEY_WOW64_32KEY angegeben wird.