Works very nicely on 32b WinXP. Not tested elsewhere.
Minor logistics issue - the 32b sysutils is a little older than the others (as downloaded from LUCKY):
2013-09-16@22:43:03 115,712 B563BF5A 4utils.dll
2013-09-16@23:23:30 131,584 6B2C3BA0 4utils64.dll
2013-09-05@09:22:35 103,936 035BEF46 sysutils.dll
2013-09-16@23:24:33 115,712 4B367C35 sysutils64.dll BTW, I also created an alias that displays the level of its parameter: DLEVEL=*echo %@dlevel[%1]
This could be made more more sophisticated, to display _dlevel if there is no parameter, and to make an error report if function value is -1. You may consider adding it as a command to complete the possibilities...
Frankly, I can't imagine a use for @DLEVEL. Earlier in this thread there was a situation in which _DLEVEL would have been useful with GLOBAL. A DLEVEL command seems way OTT. If Rex added _GLOBAL_LEVEL (same as _DLEVEL), existing only during the execution of GLOBAL, that might be enough for me.
Vince, you may be right about the frequency of use of the DLEVEL concept in any of its variations: nearly never. So is probably more than half of TCC - any one user probably uses at most a third of its capabilities. But different users use different parts. As my requirements changed, there had been features I had hotly desired and no longer use. And I agree that the DLEVEL command is certainly not necessary, my alias does it quite adequately, and it was used only to test the function. I am more interested in the functional difference, if any, between the Sept. 5 version of sysutils.dll and yesterday's version of sysutils64.dll. The sysutils.txt files accompaying them are identical.
I suspect what happened was that I did a "batch build" and the 32-bit version, being up-to-date, wasn't rebuilt. If that's what happened then the 9/5 version was up-to-date. But just in case, I rebuilt the 32-bit version of SYSUTILS and uploaded it to lucky moments ago.
Did you get a new 4CONSOLE? Please try Shift-Up at a prompt and with some output showing in the console. I'm curious about what you think. It should move the prompt up in the buffer, erasing previous lines of output as it goes. I find it useful when I want to produce multi-command output to paste here in the forum ... if I screw up a command, I can erase its output and try again.
Please list the timestamps of all current plugins (and preferrably a hash sum as well, CRC32, MD5, or both). E.g.,
for %x in (@plugin.cat) pdir/t:wu/(z r m dy-m-d"Z"th:m:s fnq) %x
which displays UTC (independent of time zone and DST). Assumption: the filename of each DLL is unique, i.e., the 32b and 64b DLLs have different names (a rule both you and Charles Dye seem to follow). This is useful because is allows to verify that the currently loaded plugin is not obsolete. It also need to list support files identical for the 32b and 64b versions only once.
Alternately, you might provide similar information for the distributed archive files instead. However, not all of us are "packrats" who retain every version of all archives, and those who choose to delete the distribution archive after successfully installing its contents (a reasonable approach disk space is low) would not be able to check if theirs is the latest version. Dates of local copies of distribution archives may reflect downloading, possibly months later than created, not content.
Note: The latest 4console.zip is dated 2012-11-27 and 4console64.zip on 2012-12-05 that I downloaded. Currently on Lucky (using PDIR through IFTP) there is a 4console.zip dated 2013-07-14, and NO 4console64.zip.
Let me know when to try again.
Incidentally, we should move this thread to PLUGINS. Please reply there...