Re: calling application procedure from a dll

J French wrote: 
I wonder
- a DLL takes a TStream as a parameter

In the main App I have a fancy decendant of TStream that reads its
data from an abacus
- the unit containing TAbacusStream is explicitly included in the DPR
of the main App
- and the DLL knows nothing about it

I suppose the DLL goes rooting around in the memory of the main App,
or does it ? The DLL knows all about TStream and has a copy of the TStream code
compiled into it
- I genuinely don't know how smart the VMTs are
- but I've a nasty feeling that some spectacular GPFs could turn up

A problem would only occur if the VMT from one module had a different layout from the VMT in the other module -- if the methods were declared in a different order, or if a new method were inserted between two others.

If the EXE were compiled in Delphi 2005, but the DLL was compiled in Delphi 5, then things would crash spectacularly. Between those two versions, TStream got several new virtual methods, in part to support 64-bit stream positions. The order of the methods' declarations determines the order of the slots in the VMT.

If the DLL tried to set the stream's Size property, it would actually end up calling the stream's GetSize method, not SetSize. GetSize wasn't virtual in Delphi 2005, so there's no VMT entry for it at all.

There is also the optimizing compiler to consider, I gather it pretty
much gives up on trying to decide what VCL it needs to include/exclude
- but ... it still makes me nervous ...

Delphi's optimizer really doesn't do much at all, when compared to what optimizers in Visual C++ or GCC do. Delphi never removes a virtual method, unless perhaps it's private, but then it might never have been made virtual in the first place.

When I create a new DLL, I rapidly snip out all that garbage about
using the shared memory manager DLL, and assume that the host App is
written in an as yet unwritten dialect.

If I want to call virtual methods across module boundaries, and I'm not using packages, then I make sure I use interfaces. COM interfaces are mostly just a formalized version of C++ and Delphi VMTs anyway.

--
Rob
.

Relevant Pages

  • Re: New Delphi roadmap is coming: NO UNICODE PLEASE!
    ... Avoids DLL hell, because it ... The app is deployed and the user is getting an error. ... instances where upgrading .NET broke things that were working. ... Coming from Delphi, this isn't any big deal of course. ...
    (borland.public.delphi.non-technical)
  • Re: How to pass 2-dimensional array to/from DLL?
    ... > instead of TStream? ... If you cannot ask the DLL up front how much memory it needs (in which you can ... Delphi has the TStreamAdapter ... so a one dimensional array would be okay? ...
    (borland.public.delphi.language.objectpascal)
  • Re: Problem closing app with big UDT
    ... Are you trying to pass the UDT between VB and Delphi, ... Passing it back and forth between a Delphi .dll to a VB application. ... ALL the data is of one of 3 types: Long, Double, or Byte array. ... In any one app, maybe, but this dll is in production use in several ...
    (microsoft.public.vb.general.discussion)
  • Re: Setting up a TMessage trap
    ... It needs to be in a DLL and to send notices back to your own ... of your main window. ... memory segment to hold the handle of your app. ... delphi isn't able to create a DLL with a shared ...
    (comp.lang.pascal.delphi.misc)
  • Re: Problem closing app with big UDT
    ... Are you trying to pass the UDT between VB and Delphi, or do you just mean that the Delphi equivalent works fine? ... All the array sizes are multiples of 4, so the 4-byte alignment should be maintained throughout unless we screwed up somewhere. ... In any one app, maybe, but this dll is in production use in several different apps, in 3 different languages. ... So coming at it from a different direction is there any way I can, just in my VB app, send and receive the structure I need without actually passing it as a structure? ...
    (microsoft.public.vb.general.discussion)