Delphi AnsiString memory handling

[ErosOlmi]

I think I've got Delphi module development working with thinBasic strings. As you know thinBasic uses OLE32 strings while Delphi has many different string types but not OLE32 strings. Delphi AnsiStrings are the one that more a re closed to OLE32 but they differ in 4 bytes (number of reference count).

I need a confirmation I'm not able to find on the web, maybe too technical.

Anyhow, this is the problem:
Delphi AnsiStrings are in reality e pointer (p) to a DWord (pDW) that stores a pointer to a memory buffer (buff).
Buff than contains 2 DWORDs followed by the real string. The 2 DWORDs numbers are used for storing real string len plus number of reference to the string (number of pointers pointing to the same string)

I managed the whoole process in this way and it seems working fine both for getting and receiving string in/out from Delphi modules. And with strings of any len.

I would like to find a confirmation on some technical paper from Borland or from other sources.
If anyone have somethink, please let me know.

Thanks a lot
Eros

[kryton9]

Eros, I don't know if you saw my other posts, but by checking some options on the compiler and linker, Both Petr and I got our code to work with strings. Their pchar is the way from all I read that Borland handles ole32 strings. I think that info is on the coding monkeys thinbasic thread. if you need the link, I can look it up, don't have it off hand.

[ErosOlmi]

Yes I saw it but pChar solve just 50% of the problem, the returning string.

In original Delphy code made by Petr there is no parsing of script strings and no string manipulation inside Delphi function. It was just returning a constant string.

I worked on parsing string from script developing a new special thinCore.dll exported function called thinBasic_ParseString_Delphi able to pass from script to Delphi modules any string, dynamic I mean.

I'm now working on returning strings, again dynamic and not pChar (that is NULL terminated) but I thing I will give up on that because to do that Delphi needs to be dependant from an external module.

Ciao
Eros

[ErosOlmi]

Also, there is no need to include debug info from the linker. If including debug info solve some GPF problems there is for sure a problem to solve. Including debug info in compiler programs completelly mess the applications introducing a lot of compiled code just to be able to handle a debugger session.

In my experiment Delphi dll is about 22Kb and not 186Kb as with debug info inside. But it is not just a matter of size (that is not a big problem). I want to understand which is the best road to go.

Thanks a lot
Eros

[kryton9]

Well this all beyond my knowledge, I just know that by trying every option I got it to work, but I didn't care for all the debug info in there as it made the files bigger and from what I read, code with debug info is a lot slower than optimized code with debug info off.

I don't know how you know all of this stuff. I try to read up on it, but it is very confusing. Good luck!!