Comspec resets

[RobN]

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?

 

[vefatica]

You could try unchecking this (OPTION, Startup).

When I tried that it didn't work for the current instance of TCC but it did for subsequently started instances.

 

[RobN]

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?

 

[David Marcus]

In what way are the subprocesses incompatible?

 

[vefatica]

This'll do it in the current instance, and, when done in TCSTART.BTM, in every instance.

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.

 

[vefatica]

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!

Edit: I have

 

[RobN]

@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.

 

[Alpengreis]

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.)

 

[David Marcus]

By "sub-processes", do you mean .bat and .cmd files? The simplest solution is to not associate these with TCC. Let cmd run them. Only associate TCC with .btm files.

 

[vefatica]

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).

 

[vefatica]

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.