When sending codepoints which UTF8-encode into 3 bytes, [..]
Although this phrasing kind of suggests you did,
I suspect you did
not test this with a DLL that was in Unicode mode (i.e., setting LOADINFO.mUnicode to TRUE and using wchar_t pointers for 'data' and 'parms'), is that right? In Unicode mode, my simple test DLL can return the maximum of 10240 characters without problems. That also makes sense, as no transcoding is necessary in that case. As such, this problem should only occur when mIRC needs to transcode from UTF-8, in which case it does seem to make sense that you can pass about 20480
bytes into the same buffer.
Instead of documenting the exact rules with respect to buffer limits for non-Unicode DLLs, I would suggest that the DLL Support help file page recommend the use of Unicode DLLs whenever dealing with non-ASCII code points. My additional two suggestions for Unicode support on the DLL Support page would be:
- change "char" to "TCHAR" in the 'procname' declaration;
- document more clearly that mUnicode is set to FALSE by default, but may be set to TRUE, which affects the types of the two string parameters in subsequent calls into the DLL.
After all, for efficiency (and of course despite the defaults that are in place for backward compatibility only), I think the general recommendation should be that new DLLs be made with Unicode support.
It should be possible to extended the DLL LOADINFO structure itself to include [the buffer size] in future versions.
Exposing the $maxlenl value to DLLs sounds like a good addition. There are many DLLs that can return large amounts of data, and being able to obtain the limits at run time will allow DLLs to be forward-compatible in terms of getting the most out of the buffer. As above, I do think this should focus on the Unicode DLL variant though.
