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
cadenzaAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
MadshiConnect With a Mentor Commented:
>> 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)

I'm sorry, but I think it's this way.

>> if you only pass self declared objects, it should be alright, isn't it?

It should be, except if Borland changes the object structure somehow. That's why I'm using interfaces for such purposes.

>> Safe also are handles, like DC handles, I guess.

Yes, they're 100% safe.

>> 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.

Yes, but not too much. And they have several advantages, too. Like reference counting, automatic deallocation and such stuff.

>> Does COM slow down execution? I mean: data marshalling will be slow, I guess.

Well, you don't need to use full COM. Delphi interfaces are a subset of COM. If you're only using interfaces (and not full COM) you should have no big timing disadvantages. The big timing difference is, that you can't make properties like this:

  property AField : integer read FAField write FAField;

You always MUST use get and set functions. But that's all about timing, I think.

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

Cheers,

Raymond.
0
Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
westy100697Commented:
Have you tried turning the Optimization Directive off or

 {$O-}


WESTY :)

0
 
MadshiCommented:
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.
0
 
cadenzaAuthor Commented:
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
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.