Originally Posted by maroon
(1) Another LOADINFO data item which indicates whether the dll was called by $dll or $dllcall.

I'm afraid this suggestion is invalid, but it it is fortunately also not needed. It is invalid because LoadDll does not get called for every DLL call. Rather, LoadDll typically gets called once (depending on mKeep etc), after which a mix of calls invoked with /dll, $dll() and/or $dllcall() may follow. Thus, LOADINFO can not be used to pass in per-call information.

However, a DLL can tell very easily whether a procedure was invoked with $dllcall() or not. For example, it can store the main mIRC thread ID with a call to GetCurrentThreadId() from LoadDll, and compare that stored value to the value returned from GetCurrentThreadId() in the actual DLL procedure. If the values are the same, the procedure was called with /dll or $dll(). If the values are different, the procedure was called with $dllcall().

Originally Posted by maroon
(2) change $dllcall syntax [..]. 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.

This suggestion I don't understand. The two main advantages of binvars are 1) they can store NUL characters, and 2) they can contain more data than regular variables. However, due to the nature of the "data" parameter to DLL calls, storing the returned data into a binvar would not help with exploiting either of those advantages. Thus, how would this suggestion be an improvement over the called alias using "/bset -t" itself?


Saturn, QuakeNet staff