In the calling program, the String should be properly counted by the garbage collector.
But in the DLL program, using Byte Ptr should avoid the usage of the GC reference counter, so as long as the function is not running on a separated thread, the string object references should be the same in the calling program, before and after the function call, so you shouldn't have to free memory. In fact, when you do text$ = string.fromcstring(htext) you're creating a new and separated BlitzMax string object. Strings are the only objects that doesn't increase reference counting when assigned. they just duplicate objects, this way, they work as if they where 'regular' variables.
And the real problem here is freeing memory when the calling program still has at last one string reference count of it (the one placed in the calling sentence).
So my advice whould be to not free memory as long as you are not creating multithread dlls. I see no way to do this without confusing the GC
But in the DLL program, using Byte Ptr should avoid the usage of the GC reference counter, so as long as the function is not running on a separated thread, the string object references should be the same in the calling program, before and after the function call, so you shouldn't have to free memory. In fact, when you do text$ = string.fromcstring(htext) you're creating a new and separated BlitzMax string object. Strings are the only objects that doesn't increase reference counting when assigned. they just duplicate objects, this way, they work as if they where 'regular' variables.
And the real problem here is freeing memory when the calling program still has at last one string reference count of it (the one placed in the calling sentence).
So my advice whould be to not free memory as long as you are not creating multithread dlls. I see no way to do this without confusing the GC