[fpc-pascal] Delphi ShareMem -DLL-pchar
memsom at interalpha.co.uk
Wed Sep 6 01:45:28 CEST 2006
> 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
> 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;
procedure freeFpcStrBuffer(buffer: pchar); //maybe size too?
if getFpcStrBuffer(b, 21) then
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
Sorry lack of sleep.. must go to bed. Hopefully that makes sense.
More information about the fpc-pascal