A couple items to make $dllcall be more useful. Right now, it's difficult for a dll to know whether it's been called by $dll the normal way, or was called by $dllcall in the background, or even that it was called by the /dll command. And, it's currently not possible for $dllcall to access the return string normally returned from a dll.
(1) Another LOADINFO data item which indicates whether the dll was called by $dll or $dllcall. I assume it's fine for the bitflag to return the same for $dll or /dll, since /dll has always been used without the expectation of output or callback.
If this is made a bitflag value, future flag bits could be added to it, without further increasing the size of the structure.
This feature would make it easier for a non-threadsafe dll to behave differently if it's been called in the background by $dllcall
(2) change $dllcall syntax from
$dllcall(<filename>,<callbackalias|/noop> [optional string],<procname>,<data|$null>)
$dllcall(<filename>,<callbackalias|/noop> [optional string],<procname>,<data|$null>[,&binvar])
The new parm would allow the .dll's normal 'return 3;' string to be filled into the &binvar instead of $dllcall sending it to the bit bucket.
The /help currently doesn't document the callbackalias other than "and will call the specified alias once the call returns".
Currently $dllcall calls the alias-parameter with $dll(filename) appended to it, so that
$dllcall(File.dll,!echo -c info,procname,data)
will call the /echo command with $1- being: -c info $mircdirFile.dll
The new behavior could also be accomplished without the 5th parm by changing the syntax to be $dllcall(filename,&binvar alias, procname, data) as long as it's not intended that &string as an alias name not be supported.