Comspec resets

Feb 17, 2022
3
0
For years I have set COMSPEC to CMD.exe in 4start.bat, because there are many sub-processes in our environment that are incompatible with TCC when they spawn.

After upgrading from v20 to v28 there is a new problem. Sometimes COMSPEC gets reset to TCC and those subprocesses fail.

This was mentioned in this thread, but never resolved: COMSPEC constantly reset to TCC.EXE

In the v22 release notes: "TCC will reset COMSPEC to TCC.EXE after a WM_SETTINGCHANGE", which seems to be the crux of the problem. Our environment appears to send out WM_SETTINGCHANGE notifications throughout the day, breaking automated jobs and user shells. This is making this version of TCC unreliable.

Is there any way to override this behavior?
 
May 20, 2008
12,049
128
Syracuse, NY, USA
You could try unchecking this (OPTION, Startup).

1645149200182.png


When I tried that it didn't work for the current instance of TCC but it did for subsequently started instances.
 
Feb 17, 2022
3
0
The option "Update environment on system change" sounded like the golden ticket, but checked or unchecked (and starting a new instance) COMSPEC still resets. By the way, it was unchecked on my machine when first reported the issue.

Any other suggestions?
 
May 20, 2008
12,049
128
Syracuse, NY, USA
This'll do it in the current instance, and, when done in TCSTART.BTM, in every instance.

Code:
set hwnd=%@winapi[user32,FindWindow,TCC.EXE,TCC:%@eval[%_pid=h]]
echo %@winapi[user32,SendMessage,%hwnd,16,0,0] > nul

As far as I know this is what the "TCC.EXE"-class window does:

1. processes the WM_SETTINGSCHANGE (Environment) message (point in question)
2. processes messages announcing logoff or shutdown
3. processes a timer message used by TCMD to determine if a tabbed TCC's console window has been un-hidden.

I used to close that window as a rule; I never noticed bad effects.
 
May 20, 2008
12,049
128
Syracuse, NY, USA
I'm still looking for ways around this (other than closing the "TCC.EXE" window). I noticed a very peculiar behavior (see below). COMSPEC is set (to CMD) in the System environment and TCC sets its COMSPEC to itself (as expected). Here's a new instance of TCC. Does anyone have an idea why setting and unsetting COMSPEC in the User environment changes TCC's COMSPEC environment variable? I have no idea what's going on!

1645307588821.png


Edit: I have

1645307917941.png
 
Feb 17, 2022
3
0
@vefatica: this trick of closing the TCC window works and solved the issue. I was able to test this by doing SendMessage with a "26" which is WM_SETTINGCHANGE - if I hadn't closed the window it would reset COMSPEC, and if I had closed the window with your command then it doesn't reset. Thank you for this suggestion.

I still don't understand what is actually getting closed though. I thought the TCC window (where I type) would go away, but it
does not. What is actually getting shut down, and is there any side effects from this?

@David Marcus : The incompatibility I'm currently seeing is with the space in "Program Files". Certain sub-processes attempt to spawn new jobs, and fail to spawn TCC with the space because they reparse the command line and don't properly escape it. Another work around might have been installing to a different location without a space, but in the past I have seen other incompatibilities too, so decided to stick with changing COMSPEC.

Thanks.
 
Jan 12, 2014
502
9
Switzerland, SO
Maybe the following entry in TCMD.ini under section [4NT] could help (too)?

CMDBatch=Yes

From help:

If set to "Yes", TCC will run all .BAT and .CMD files in a CMD.EXE shell. (For those of you using poorly-written batch files that depend on CMD bugs or undocumented behavior.)
 
May 20, 2008
12,049
128
Syracuse, NY, USA
I still don't understand what is actually getting closed though. I thought the TCC window (where I type) would go away, but it
does not. What is actually getting shut down, and is there any side effects from this?
The window where you type is the console window, created automatically by Windows to host TCC, a console application. TCC doesn't have to create a window but it does for the purposes I mentioned earlier. It is a top level window (i.e., not a child window) so it will get all the messages it's meant to process. It is not shown. It's class name is "TCC.EXE" and it's caption is "TCC:xxx" where "xxx" is TCC's process ID in lowercase hex.

FWIW, using @WINAPI, I tried both ChangeWindowMessageFilter (app-specific) and ChangeWindowMessageFilterEx (window-specific) to disallow WM_SETTINGCHANGE. Neither worked (as the docs suggest can happen).
 
May 20, 2008
12,049
128
Syracuse, NY, USA
P.S., the side effects are that the three things I mentioned don't happen.

If TCC doesn't get/process WM_QUERYENDSESSION (and friends) it could terminate quicker than expected when a logoff or shutdown is pending. Windows sends that message to top level windows and waits (only briefly) for them to respond.

I also mentioned a WM_TIMER mechanism (which won't be in effect if the TCC.EXE-class window is closed). I'm pretty sure it works like this: polling occurs every half-second ... if TCC is running in TCMD (console window hidden) and the console window was forced to be visible, it's hidden again.