OK, from testing with
variable = GetCurrentThreadId();
it looks like LoadDll is invoked using the same thread ID which will eventually be used by $dll, even if the DLL is being loaded by $dllcall, and is different than the thread ID seen by the procname being executed by that $dllcall usage. So by saving that ID during LoadDll to a global variable, that lets a procname know whether it was called using $dllcall or not.
As for a 5th parm containing the &binvarname, that may not be the best solution, because it would also require the callback alias be given a way to know which &binvarname was used. The current behavior of $dllcall(File.dll,callbackalias foo bar,procname,data) is to invoke the callbackalias with $1- being "foo bar $mircdirFile.dll", so the callbackalias would need adding &binvarname to the 2nd parm as a parameter, which may not be good for $dllcall to assume &string in parm2 is the name of the &binvar.
If backwards compatibility needs to be preserved with current behavior of the $1- for the callbackalias, perhaps a better solution would be a new $callbackstring kind of identifier which would contain the normal return3 string. Having the same temporary scope as $nick is probably sufficient, as opposed to the longterm nature of $msfile(1) or $readn.
