mIRC Home    About    Download    Register    News    Help

Topic Options
#265132 - 11/03/19 06:18 PM $dllcall clarify
maroon Offline
Hoopy frood

Registered: 12/01/04
Posts: 1109
$dllcall(filename, alias, procname, data)

Is it feasible to have a parameter where this passes more than $longfn(filename) back to the alias?

That would make $dllcall more useful to allow a dll to perform a slow task and report the answer later. Enabling support for a dll which doesn't store the results then waits for the alias to make a procname call to fetch it.

Top
#265136 - 11/03/19 10:33 PM Re: $dllcall clarify [Re: maroon]
maroon Offline
Hoopy frood

Registered: 12/01/04
Posts: 1109
To clarify with an example. At Saturn's website, his sha2.dll can hash a large filename like:

//echo -a $dll(sha2.dll,sha224,reallybigfilename)

and the 'return 3' answer can be stored in a variable or echoed. However, it can freeze mIRC's focus when the filesize is very large.

The description for $dllcall makes it seem like you can have the dll work in the background and report the answer to the alias when finished.

//echo -a nothing on this line $dllcall(sha2.dll,echo 4,sha224,0 abc)

Instead, this shows the dll's full pathname\filename in red, but returns no other info.

Perhaps a 4th parameter to allow the normal 'return 3' output to be filled instead into a binvar similar to the way regsubex does

$dll(filename,procname,[datastring],[&binvar]) would return $null and instead fill the binvar.

$dllcall(filename,alias,procname,datastring,[&binvar])
... could maintain backwards compat by continuing to return $1- to the alias filled with the path\filename, but the presence of the &binvar parameters could make it give the alias' context a &binvar containing the 'return 3' string instead of discarding it.

Top
#265188 - 14/03/19 04:51 PM Re: $dllcall clarify [Re: maroon]
maroon Offline
Hoopy frood

Registered: 12/01/04
Posts: 1109
After a little testing with $dllcall(), other things that might be useful for it:

* Some way to identify how many dllcall processes are running, and which ones they are. I know the $dllcall() parameter can include text on the commandline sent to calledalias to identify which of several dllcall() events is being returned, but there isn't a way to identify info about any dllcall processes running in the background, other than /dll -u fails if it's within a dllcall process.

* some way to safely unload a dllcall() process that can't be made to exit with /dll -u

* a bitflag variable filled during LoadDll which informs things like:
+ whether this is a $dll() or $dllcall() that's loading
+ whether this dll is already running in the background under another $dllcall()

A bitflag makes it easy to add future info without needing to fine new fields, as long as the dll knows not to assume that not-yet-defined bits would be 0's.

* Something a DLL can do during LoadDll to set a flag telling mIRC to halt the load if there's already a dllcall process running in the background, as well as being able to set a flag telling mIRC to halt this load attempt for whatever reason.

Because dllcall() is multi-thread, dll's using global variables are very likely not going to do well with having 2 processes run at the same time. So dll's might want to deny the attempt to call them using dllcall(), or to allow that if they can deny being launched as a normal dll() launch while there's a dllcall() process running in the background.

As a test, I used dllcall() to give a .dll the task of calling a subfunction 0xf0000000 times, where one thing the subfunction did was incrementing a global dll variable. When run as a dllcall() by itself, the end value of the counter increased correctly. While the dllcall() ran in the background, I ran the .dll with several dll() commands which each made 1 attempt to bump the counter, and a high percentage of the extra bumps were missing from the counter's ending value.

I then launched 2 identical dllcall() prcesses to each increase the counter by 0xf0000000. Instead of the ending value being +0x1e0000000 it was only +0x12d7b9b33, indicating the non-threadsafe usage had missed 37% of the bumps to the counter.

Top