Packages in anderem Verzeichnis

[Kas Ob.]

OK, with the registry trick above, it works only with ShellExecute, with the debugger executing the application with CreateProcess will not work.
If you run the exe using Windows Explorer then it is fine and the DLL will be found and loaded, but other executing method might not work !

[himitsu]

LoadPackage, aber das geht natürlich nicht bei statisch eingebundenen Packagages. (genauso, wie LoadLibrary bei DLLs)


Side-by-Side Manifest (SxS) : <PackageDependency> in <Dependencies>
bekannte Libraries : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs
oder, was eben über die Standard-Suchpfade zu finden ist, welches diese Unterverzeichnisse nunmal nicht beinhaltet.

und
SetDllDirectory
LoadLibraryEx + LOAD_WITH_ALTERED_SEARCH_PATH
gehen halt erst zur Laufzeit und demnach nur beim dynamischen Laden

[hschmid67]

erst einmal Euch allen ein dickes Danke! Es ist wirklich großartig, hier solche engagierte und kompetente Hilfe zu erhalten

Nun, die Überlegungen von Kas Ob. sind sehr interessant und haben mir ein wenig Einblick in die Funktionsweise einer exe und Windows gegeben. Ich fürchte, dass ich das aber nicht tun kann, weil ich die Zielsysteme nicht so weit manipulieren möchte. Mein Programm soll eigentlich kaum einen Hinweis auf sich im System, in der Registry hinterlassen - und da ist das Ändern der Path-Variablen schon mehr als eigentlich gewollt. Danke dennoch für die interessanten Ideen, die ich sicherlich für mich weiterverfolgen werde.

Spannend finde ich den Vorschlag von Herrn Müller (dummzeuch), der auch noch andere Vorteile hätte, wie er schreibt. Das werde ich mir genauer ansehen. Einziger Wermutstropfen ist, dass meine Programmstruktur noch komplizierter wird. Aber da das mit den bpl-Dateien und manchen eigenen dll-Dateien eh schon nicht einfach ist, macht das wohl auch nicht mehr viel aus.

Rein verständnishalber würde mich noch die Idee mit dem

Code:

LoadPackage

interessieren. Wenn ich über die Programmoptionen ein Package einbinde, dann ist das wohl statisch. Das Programm wird mit diesem Package kompiliert und alles aus dem Package ist dann statisch eingebunden. Die Exe-Datei wird kleiner und ich muss nichts irgendwo extra deklarieren. Wenn ich ein Package mit LoadPackage einbinde, wie funktioniert das dann mit dem Verwenden der Routinen und Classen des Packages? Muss ich dann ähnlich wie bei LoadLibrary erstmal alle Routinen und Klassen extra deklarieren, oder kann ich die Unit aus dem Package einfach so wie beim statischen Einbinden nutzen. Damit hab ich mich bisher überhaupt nicht beschäftigt und verstehe das mit den Packages gar nicht.

Also nochmal vielen Dank Euch allen und viele Grüße
Harald

[jaenicke]

Zitat von hschmid67:

Wenn ich über die Programmoptionen ein Package einbinde, dann ist das wohl statisch. Das Programm wird mit diesem Package kompiliert und alles aus dem Package ist dann statisch eingebunden. Die Exe-Datei wird kleiner und ich muss nichts irgendwo extra deklarieren. Wenn ich ein Package mit LoadPackage einbinde

Dann funktioniert das nicht. Denn der Compiler benötigt zum Kompilieren die Information, woher die Typen kommen usw., was nur mit Laufzeitpackages extern funktioniert. Später geladene Packages kann der Compiler nicht berücksichtigen. Denn nur bei Laufzeitpackages ist sichergestellt, dass diese bei Verwendung eines Typs auch geladen sind.

[dummzeuch]

Mit LoadPackage kann man zur Laufzeit weitere Packages einbinden, die für die Funktion optional sind. So, wie die IDE das für Package-basierte Plugins und auch mit den Designtime-Packages der Komponenten macht.

Ich habe mal eine Zeit lang damit geliebäugelt, das für unsere internen Programme zur Modularisierung zu verwenden, aber da die Voraussetzung ist, dass man die Delphi RTL und VCL ebenfalls als Packages einbinden muss, habe ich wieder davon abgesehen. Da Du aber sowieso mit Runtime-Packages arbeitest, wäre das eine Option.

[Kas Ob.]

LoadPackage will not be much of a help here, as itself (LoadPackage) does exist within RTLxxx.BPL, so even if you managed to change you application and remove all the designtime packages from the IDE designer for all the auto-created forms/frames/modules you still will have trouble to handle RTLxxx.BPL and most likely VCLxxx.BPL with fewer others.

There is other solution i didn't mention before, but because you are interested i will explain it, but before that i will include this small loader, that works perfectly everywhere (i hope) with any adjustment to OS settings, namely the path in environment:

Delphi-Quellcode:

program Loader;
// This application is VCL application and not console/cmd, we don't need the console window to pop every time and scare everyone!!
uses
  Windows;

{$R *.res}

const
  APPLICATION_EXE_NAME = 'DelphiRuntimeTest.exe';
  APPLICATION_EXTRA_COMMANDLINE = '';
  APPLICATION_PATH_TO_ADD ='D:\Program Files (x86)\Embarcadero\Studio\16.0\bin';

procedure SetPathAndRun;
var
  si: TStartupInfo;
  pi: TProcessInformation;
  Path:string;
  PathLen:Integer;   // length in characters
begin
  // adjust the path
  PathLen := GetEnvironmentVariable('PATH',nil,0);
  SetLength(Path,PathLen);
  GetEnvironmentVariable('PATH',@Path[1],PathLen);
  Path := APPLICATION_PATH_TO_ADD +';'+Path;                  // we add out path first to skip handling the null terminator
  SetEnvironmentVariable(PChar('PATH'), PChar(Path));
  //SetEnvironmentVariable(PChar('PATH'), PChar(APPLICATION_PATH_TO_ADD+';%PATH%'));  // this might be enough though, instead of all above

  // run and don't wait
  ZeroMemory(@si,SizeOf(si)); //si := Default(TStartupInfo);  // ZeroMem for old Delphi versions
  si.cb := sizeof(si);
  CreateProcess(PChar(APPLICATION_EXE_NAME),                  // EXE Name with or without path
    PChar(GetCommandLine + APPLICATION_EXTRA_COMMANDLINE),    // this will pass the same command line to the exe with the extra
    nil, nil, False, 0, nil, nil, si, pi);
end;

begin
  SetPathAndRun;   // will run the exe and exit without waiting
end.

The other solution is to look and understand how packers works, namely UPX for the easy understanding.
UPX is executable packer, that strip and compress sections ... bla bla, we care about one thing here, how it does handle the import table, UPX strip/remove the functions leaving only one from each statically loaded/imported DLL, then when it is unpacking the exe it does resolve the rest, from its own stored and compressed table.
The reason to strip them all, because that table is not optimized on byte level, and might be big, but that is irrelevant as UPX tries to squeeze space every where it can, the question is why it does leave one ?
The answer is: for two reasons first security, it doesn't want to irritate AV(security analyzing software) more than needed, and secondly to keep the OS behavior consistent when loading and handling DLL, so it doesn't go to full length and loaded the libraries on its own and resolve the import addresses, this for compatibility and also will keep the unpacker code as small as it could be.

What can be done here is:
UPX is on GitHub with license GPL-2, but it does some changes, we need to remove the one imported function and replace them with your slightly adjusted table.
This solution should work, but the work and changes could be not-so-practical.

Anyway, wrote this as food for thought.

[himitsu]

Anstatt des Suchpfad des Parent-Prozesses zu verpfuschen,
wäre es bestimmt schöner das Environment als Parameter an CreateProcess zu übergeben.

[himitsu]

Delphi-Quellcode:

  var Environment := TStringList.Create;
  Environment.TrailingLineBreak := True;
  Environment.LineBreak := #0;

  //Environment.StrictDelimiter := True;
  //Environment.Delimiter := #0;
  //Environment.DelimitedText := GetEnvironmentStrings;
  var P := GetEnvironmentStrings;
  var S: String;
  while P <> '' do begin
    Environment.Add(P);
    Inc(P, Succ(Length(P)));
  end;

  Environment.Values['PATH'] := Environment.Values['PATH'] + ';' + TPath.Combine(TPath.GetAppPath, 'Version_1.0.0');

  var Test := Environment.Text;
  //CreateProcess(ApplicationName, CommandLine, ProcessAttributes, ThreadAttributes, InheritHandles, CreationFlags, PChar(Environment.Text), CurrentDirectory, StartupInfo, ProcessInformation);