I was tempted, in the absence of more informed opinion, to wonder if the BAT / BTM test had been accidentally inverted since v17 ;) Rather more scientifically, I used procmon.exe to monitor the tcc.exe process, see attached tt4.zip content. I simplified the script tt4.bat / btm (timings on v23...

I find the significant fact is that executing IF ISLABEL ... just 9 times takes some 27 seconds longer in a BTM file than a BAT file. The BTM script should read 5000 lines once and store them in memory which is searched 9 times. This takes 28.6 seconds. The BAT script should read and search 5000...

I can't see how "BAT is going to win by loading 1K" when BAT must surely also load 500K to execute the statement if islabel NO_SUCH_LABEL echo never

Indeed LOADBTM is irrelevant (in this particular case). I've attached a dummy TT.BAT that illustrates the timing difference. The script in its entirety is: @echo off setlocal timer ON set COUNT=9 do N = 1 to %[COUNT] if islabel NO_SUCH_LABEL echo never enddo timer OFF echo %[_batchname]...

A belated thank you for the explanation. With due respect (and speaking as a computer programmer) the explanation misses the viewpoint of the (this?) user who expects things just to work ... Slowing "ZIP down enormously" in this instance would have saved me several hours of testing, diagnosis...

Having been a user of tcc in it's various manifestations since 4dos days, I was a believer in the "BTM files are faster than BAT files" mantra. But a few nagging doubts led me to test TT.BAT, a script of 5000+ lines. I ran this with two tcc versions: TCC 23.00.25 x64 Windows 10 [Version...

setlocal rem TCC 23.00.25 x64 Windows 10 [Version 10.0.17134.471] ver set CurDir=C:\tmp\cwd if not isdir %[CurDir] md %[CurDir] set LogDir=C:\tmp\zip if not isdir %[LogDir] md %[LogDir] cdd %[CurDir] del %[LogDir]\test.zip %[LogDir]\*.txt echo Test1 >%[LogDir]\Test1.txt echo Test2...

Further googling led me to https://technet.microsoft.com/en-us/library/mt427362.aspx for the new console features. The option "Use legacy console" restores the old alt-F4 behaviour :)

I'm running TCC 17.00.77 x64 on Windows 10. I recently upgraded from windows 8.1 where my key alias: @@alt-f4=echo exit & exit worked fine, running tcexit.btm to completion. In windows 10 tcexit.btm does start but the console closes before it completes...

I also had the same problem on 64bit Windows 8.1 and wish I'd seen TEA-Time's excellent analysis earlier. I have now upgraded to Windows 10 and TCC 17.00.77 x64. The problem has now become a memory exception. Pressing F1 on the command prompt shows: TCC has stopped working etc. The stack...

The script tcc_quirk.bat manages to create a file "%[CmdLog]" from the command %[Cmd] >& %[CmdLog] when the command (the Cmd variable) contains an IF statement. For example: Code: set Cmd=if not isdir \t\tcc mkdir \t\tcc set CmdLog=\t\tcc\whatever.log %[Cmd] >"%[CmdLog]" . The uploaded...

I spent about a day tracking down and finally reproducing a strange crash in TCC. The crash occurs on a gosub with arguments to a label in a named script. Later .. I found an easier way to reproduce. Create two batch files: BUG1.btm setlocal set BUG1=%[_batchname] call Bug2.btm quit...