I'm afraid you're misinterpreting the text from Microsoft. The full text shows that "reserved" means "set aside for that purpose in the process's virtual address space" in this context. It does not mean that all of that virtual address space has physical pages backing it. The virtual stack pages will only have associated physical memory if they 1) are part of the initially committed set, or 2) have been actually used at some point. Thus, increasing the maximum ("reserved") stack size does not automatically lead to more memory usage. On the other hand, once a stack page has actually been used at any point, it basically cannot be freed anymore, so that in mIRC's single-threaded case..
Thanks, I did understand that it was not committed memory. Perhaps I should have stated that in my post. My point was that if every application reserved and used stack space without consideration, it would have a negative effect on the system as a whole. Since Microsoft recommends that as little stack space is used as possible, it would be better for mIRC to stay as close to that recommendation as possible. That said, I increased it somewhat unwillingly a few years ago from the default 1MB to 2MB (as an extra precaution, in addition to limiting recursion depth, in order to mitigate freezes\crashes related to recursion) so extending it even further is something I would prefer to avoid.
Update: I forgot to mention that I found a way to make the script parser determine the exact remaining stack space during recursion. The method seems to work correctly under XP, 7, 8.1, 10, and Wine. It allows the script parser to more precisely determine whether it can continue with a recursive call and to use more of the available reserved stack space, while still providing a conservative buffer. This increases recursion depth from about 250 to about 4000. The actual maximum depth will depend on the whether command/identifier calls are used, and which commands/identifiers are used, as some may have longer call chains than others.
