Whoa - I guess I never knew that. I wonder if that behavior was added later - I was pretty sure that didn't work or resulted in massive memory leaks. Checked briefly and sure enough it works without leaking. Thanks for pointing this out...

Regardless though, this will only work with methods that are properly exported with Win32API export rules. Any `raw` C/C++ functions won't just work and any API that follows Win32API rules *generally* uses OUT parameters to return values.

+++ Rick ---

>>You can't call a DLL function that returns a string because there's no way for FoxPro - at least not without an FLL in between - to capture the pointer that the function returns. CDecl calling convention generally doesn't work - you can only really call DLLs with WINAPI calling convention which has all APIs pretty much returning numeric values and any 'real' return values returned in passed in buffers.
>>
>>Your best bet is to wrap the function in a .NET DLL and call it with wwDotnetBridge or plain COM interop.
>
>Rick,
>
>Yes, you can call a dll that returns a string. Done it in the past
>It is my understanding that FoxPro allocs a string with the return value ( char*)
>
>
>Been looking for an example - https://msdn.microsoft.com/en-us/library/windows/desktop/ms647474(v=vs.85).aspx
>
>Now, how you declare and use it in C# - I don't know , tried with IntPtr but only the first char is returned (and converted to upper case)
>
>

>function CharUpperTest()
>	
>	declare string CharUpperA in user32.dll string s
>	
>	local x,s
>	s = 'abc'
>	
>	x = CharUpperA (m.s)
>	
>	&& assert false
>endfunc
>