Link to home
Start Free TrialLog in
Avatar of cadenza
cadenza

asked on

DLL + APP different Delphi versions

I have an application that loads DLLs it can find (after checking they are the right type...). Both app and DLLs are developed by myself. The app passes the Application variable to the DLLs and receives a reference to an object created by the DLL. The app e.g. calls methods of these objects. I build with run-time packages and have ShareMem as the first 'used' unit in the .dpr files. This was all done in Delphi 4

All went fine so far. Now I try to develop a new DLL, but in Delphi 5 this time. I get some weird problems in the main app, like for loops going beyond the upper bound.

Is this what I have to expect when using this approach and combining a Delphi 4 app with DLLs built in a different Delphi version? And how about DLLs built in C++ Builder?

If so, what do I have to change to make it work for different versions of app and DLL? I can not simply rebuild every time a new DLL is developed, since they may come from many different persons (and companies)

Wim
Avatar of Epsylon
Epsylon

Some things changed in the alignment of record fields. I don't know if you exchange records between the main app and DLL's.....
Can you show us some code snippets?

Cheers,

Raymond.
Have you tried turning the Optimization Directive off or

 {$O-}


WESTY :)

The main problem I see is the application object. It may be different in D4 and D5. So if you give in the D5 application instance to the D4 DLL, and the D4 DLL tries to access this application instance as it was a D4 application instance, you might get into serious trouble.
Is there no other way than passing the application instance to the DLLs?

If you want to go the other way (passing objects from the DLL to the application) you can run into the same problems, depending on which objects you're passing. Which kind of objects do you pass from the DLL to the app? Self declared objects? Or VCL objects? The most secure way would probably be to pass interfaces. They are guaranteed to stay the same forever, since that is what is used in COM, too. Look at TInterfacedObject and the keyword "interface", if you're interested in that.

ShareMem should work alright for D4 and D5. BTW, you know that you have to ship this borlndmm.dll (or how the name was) with your application when using ShareMem, don't you? I can give you a "magic" ShareMem unit (written by myself) with which you don't need that borland dll. Interested?

Regards, Madshi.
Avatar of cadenza

ASKER

Epsylon:
I know. I turned alignment on in all cases. Does not help, though.

Raymond:
this would be quite a lot, since app and dll interact quite a bit. I'll try to isolate the essential code that still has this problem. Since this will take a lot of time, I was hoping someone would be able to tell from the info I already gave what I am trying is bound to fail or should work.

Westy:
optimisation is off for app and dll

Madshi:
what you are saying is: don't pass VCL objects between app and dll, since they may be version dependant. This is the answer I feared most :0)
if you only pass self declared objects, it should be alright, isn't it? Safe also are handles, like DC handles, I guess.
I'll have a look at interfaces again. I did so before and thought I'd better avoid them if I can, since it adds complexity. Does COM slow down execution? I mean: data marshalling will be slow, I guess.
Yes, I am interested in your magic unit. Can it be shared across versions? Thanks a bunch! My email address is: cadenza@worldonline.nl

Thanks all for your replies so far. I am going to sit in a corner and think things over.

Wim
ASKER CERTIFIED SOLUTION
Avatar of Madshi
Madshi

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial