Run-time package load vs static linking

Question

So, I have a myself written run-time package. If a package is statically linked, the project that uses has full access to exported data because the compiler has full knowledge of what is imported from it, am I right? But it's also possible to load a package dynamically via LoadPackage(). But, how to work with imported complex data structures like classes then? I couldn't find a feasible way other than constructing complex expressions like using FindClass('TSomeClass') and invoking RTTI to operate on an instance of the imported class.

Answer 1

Short answer:

What you need is the compiler/linker to set you up and use DCPs to do all the linking to types and such.

Then loading of BPLs should be delayed/done by you in custom code.

Unfortunately Delphi won't allow this, probably because of political reasons, you could try and hack it though, see below for more thorough answer.

Long answer:

Apperently DCP describe to the compiler/linker/Delphi yadayadayada what's in those packages/DLLs/BPLs type-wise.

These DCPs can be considered the interface to these DLLs/BPLs, these DCPs are probably somehow compiled into the executable.

Then the BPL probably contains the "implementation".

Now here is where the problem begins. These BPLs are "auto-loaded" as somebody else already mentioned by mentioning "import table".

What you could try is "nuking" / altering the import table so that these BPLs are not loaded automatically anymore.

Then you could try loading these BPLs manually.

I am not sure if it's just as simple as doing a "load package" operation.

Perhaps the loading involves more like acquiring pointers to routines/methods/classes, not sure how that works.

However perhaps that code can be re-used, so all you need to do is "hack" into the import table and hack into the "load bpl" and disable it.

Then you should be able to replace that with your own custom loading code and perhaps finally "re-patch" into other importing routines... like routines calling getprocaddress and such if so required, not sure about this last part.

Anyway this is very sloppy from Delphi developers that there is no functionality to do this little "import table"/"load step" yourself.

This is politics at play though, there is no technical reason why this could not be delayed, done custom by you and then call the rest if necessary.

For some reason they do not want you loading these BPLs manually. They probably want you to keep using the IDE this way.

If you were able to load these things manually, maybe the IDE would then no longer be necessary.

Currently the IDE is necessary to specify where to load this stuff from, without the IDE it will get difficult. Though there are probably also some compiler options somewhere to specify the same, though few would use that.

So to me it seems some very weird "tie-in" into this product, which I honestly must admit is pretty fucking retarded.

They did the same with winsock for example which has two different versions, very easy to load this yourself manually so you can choose which version to use instead of always v1 or v2. For easy for them to delay these getprocs and such, yet they do not...

If they did, Delphi would be much more backwards compatible with windows 95/98, currently Delphi exes no longer works for those older operating systems, though there is no real technical reason why it could not work, it basically has to do with which DLLs are loaded, just a few lines of code could very easily make it work.

This is probably again politics as play to make Delphi only support the latest Windows versions a deal struck between Delphi creators and Microsoft.

Same thing with Windows 10, it apperently detects older processors and then refuses to run on them, removing/hacking these few lines of code/instructions will make Windows 10 work on older processors. Surprise ! =D