Delphi ShareMem -DLL-pchar

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Delphi ShareMem -DLL-pchar

afpTeam
Hi,

Can anyone comment on the Delphi unit "ShareMem" and if FPC ever did any
work to incorporate what this Delphi unit is doing for DLL shared memory
managment?  I'm looking so far, at the docs on creating a memory manager,
and at the strings unit, which has some pchar utilities in it.

This article, http://delphi.about.com/od/objectpascalide/l/aa103003a.htm 
explains much about the Delphi related, Win32 DLL pointer and shared memory
problems.  I'm working on creating a DLL between two Win32 applications, but
having a lot of exception and pointer related problems to do with pchar and
asciiz data transfer.

Simple type casting is definately out.  And when exchanging Asciiz data
through a DLL between two Win32 applications, it appears that reserving &
freeing memory for passing pchars, may not be an adequate solution either as
the Win32 apps rely on Win32 API to do a lot of management behind the scenes
for parameter passing/DLL.

Worse, the data on the client side of my DLL is passing var ref variant type
parameters with only one true shortstring parameter among 8 other variants
and the return is a shortstring also.

Accordingly, I'm trying to decide whether to manage the pchar data more
aggressively, or move to a different string construct, or fall back to an
EXE with with socket/server, which would allow me to still access the server
side app via it's DLL directly and the client side App, via the socket,
(this would let me remote that side of the application anyhow, which might
be nice and would get rid of the variant types).

Thank you for any comments, suggestions, opinions or other questions I can
clarify.

AFP



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0635-5, 09/04/2006
Tested on: 9/5/2006 5:59:10 PM
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Delphi ShareMem -DLL-pchar

Matt Emson
> Can anyone comment on the Delphi unit "ShareMem" and if FPC ever did any
> work to incorporate what this Delphi unit is doing for DLL shared memory
> managment?  I'm looking so far, at the docs on creating a memory manager,
> and at the strings unit, which has some pchar utilities in it.

I don't use it any more. I use FastMM or BucketMM.

you only really need SHareMem if you are passing String types
(string/AnsiString etc) to a DLL. It doesn't sound like you're doing that.

Beware, Sharemem is slow and buggy in my experience. Also, you would need
sharemem in FPC as Delphi assumes you are sending your Delphi types
(strings, classes etc), that dictate you need Sharemem, to another Delphi
process.


> This article, http://delphi.about.com/od/objectpascalide/l/aa103003a.htm 
> explains much about the Delphi related, Win32 DLL pointer and shared
> memory problems.  I'm working on creating a DLL between two Win32
> applications, but having a lot of exception and pointer related problems
> to do with pchar and asciiz data transfer.

the only way to avoid issues is to make sure the process that allocates the
buffer deallocates it. That fixes most issues. C gets round it because you
generally use the same compiler and Malloc etc. With Delphi and FPC, you are
going to have issues because they are two completely different compilers.

I'd do something like:

function getFpcStrBuffer(buffer: pchar; const size: integer): boolean;

and

procedure freeFpcStrBuffer(buffer: pchar); //maybe size too?

then

var
  b: pchar;
begin
  if getFpcStrBuffer(b, 21) then
  try

     callAFpcDllRoutine(b, 21);

  finally
    freeFpcStrBuffer(b);
  end;

Do that in the DLL yhou want to pass data TO. So FPC would implement it, for
example. Get the Delphi code to then allocate and free buffers using that
routine. Something ike that.

Avoid using STRING/ANSISTRING/WIDESTRING when passing to a DLL like the
plague.

Sorry lack of sleep.. must go to bed. Hopefully that makes sense.

M

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Delphi ShareMem -DLL-pchar

afpTeam

----- Original Message -----
From: "Matt Emson" <[hidden email]>
To: "afpTeam" <[hidden email]>; "FPC-Pascal users discussions"
<[hidden email]>
Sent: Tuesday, September 05, 2006 7:45 PM
Subject: Re: [fpc-pascal] Delphi ShareMem -DLL-pchar


>> Can anyone comment on the Delphi unit "ShareMem" and if FPC ever did any
>> work to incorporate what this Delphi unit is doing for DLL shared memory
>> managment?  I'm looking so far, at the docs on creating a memory manager,
>> and at the strings unit, which has some pchar utilities in it.
>
> I don't use it any more. I use FastMM or BucketMM.
>
> you only really need SHareMem if you are passing String types
> (string/AnsiString etc) to a DLL. It doesn't sound like you're doing that.
>
> Beware, Sharemem is slow and buggy in my experience. Also, you would need
> sharemem in FPC as Delphi assumes you are sending your Delphi types
> (strings, classes etc), that dictate you need Sharemem, to another Delphi
> process.
>
>
Good.  Especially that I don't have access to the Delphi program itself,
only that it provides a DLL stub interface, but that's part of the
problem... the authors chose to use variant types as the parameters being
passed, so as I write a DLL to interface with it, I'm being force- fed large
allocation variant types, having to use largestring models and but only a
single shortstring that comes along for the ride with the variants.
Fortunately, as this is the client side, I can do a socket interface to that
half of the two apps and still survive, even remote the application if I
choose to.

The other app, which is serving data to my DLL and hense to Delphi through
my DLL, is a more modern platform and has a much more germane approach to
Win32 memory management.  It has been interfaced with VB and several other
newer compiler based apps, quite succesfully.  It is the one however, which
is dictating AsciiZ, but then showing examples of "String" type to be fed to
it, rather than pchars.  I was successful in exchanging data to it with FPC,
even typecasting pchars to it, via an EXE, and hopefully that may fare well
in a DLL also, so long as I don't have to convert that back to Delphi
variants, but just send to Delphi, via socket.   Damn, is that ugly, or
what?  LOL

>> This article, http://delphi.about.com/od/objectpascalide/l/aa103003a.htm 
>> explains much about the Delphi related, Win32 DLL pointer and shared
>> memory problems.  I'm working on creating a DLL between two Win32
>> applications, but having a lot of exception and pointer related problems
>> to do with pchar and asciiz data transfer.
>
> the only way to avoid issues is to make sure the process that allocates
> the buffer deallocates it. That fixes most issues. C gets round it because
> you generally use the same compiler and Malloc etc. With Delphi and FPC,
> you are going to have issues because they are two completely different
> compilers.

Agreed.

> I'd do something like:
> function getFpcStrBuffer(buffer: pchar; const size: integer): boolean;
> and
> procedure freeFpcStrBuffer(buffer: pchar); //maybe size too?
> then
>
> var
>  b: pchar;
> begin
>  if getFpcStrBuffer(b, 21) then
> try
>     callAFpcDllRoutine(b, 21);
>
>  finally
>    freeFpcStrBuffer(b);
>  end;
>
> Do that in the DLL yhou want to pass data TO. So FPC would implement it,
> for example. Get the Delphi code to then allocate and free buffers using
> that routine. Something ike that.
>
> Avoid using STRING/ANSISTRING/WIDESTRING when passing to a DLL like the
> plague.
>
> Sorry lack of sleep.. must go to bed. Hopefully that makes sense.
>
> M
Thanks for the suggestions.  Ditto sleep.  Will try some tomorrow but mostly
you're suggesting the same thing I think I've been seeing.

Thank you.

F



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0635-5, 09/04/2006
Tested on: 9/5/2006 11:27:18 PM
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal