echo Goedenmiddag! EXIT
IDE did hang after the exit ("waiting-cursor" forever).WAD, and not a crash -- EXIT tells TCC you want to shut down the session. And it does.
Assuming you're in a console session (not a TCMD tab window), the title change is being done by CMD, not IDE.Minor "issue": if you start IDE.exe from a CMD prompt, afterwards the window title is set to "ide" and the prompt is not shown. [Enter] fixes that last one.
I created a "TCApp.BTM" that just echos something and waits for a key before quitting. I tried starting AppDispatch.BTM with an "auto" argument and ran the batch debugger both from a TCC console window and a TCMD tab window. It worked perfectly chaining directly in both cases (and also when using CALL).Source is linked to this message.
You are right, the title change *is* done by CMD. When you strart "ise.exe", everything OK; starting "ise" (without the .exe) gives the new ise title right away. To make sure I copied ide.exe to abc.exe and started "abc" : title = abc.Assuming you're in a console session (not a TCMD tab window), the title change is being done by CMD, not IDE.
The deferred action is executed when the current batch file exits. That means if you chain to another batch file without a CALL, the DEFER will be done before executing the second batch file.I do think there is a vulnerability here, somewhere. If I may suggest something - what might be a rare condition and perhaps therefor untested - is:
process A (deferring something) - chaining to B - chaining to C
When is the deferred action executed? Before B or after C? Just a thought.
The crash is actually in Microsoft code (as was shown by the exception address). I was able to reproduce it and track it that far.Sorry. It took a while to get back at you.
Enclosed two screenshots. "Crash" should be understood as an unhandled exception in IDE.exe, followed by an Access violation, followed by a restart of the IDE/debugger.