Documentation help topics: %_dos & tcc /n

[Frank]

• %_dos:

The help says "Windows 7" -> "WIN7", but I get "WINDOWS7".

• %_service:

"_service returns 1 if TCC was started as a service (TCC /N)."

I can't find more info to this in the help. How can I use "TCC /N"?

 

[rconn]

• %_dos:

The help says "Windows 7" -> "WIN7", but I get "WINDOWS7".

WAD. I've corrected the documentation for the next build.

"_service returns 1 if TCC was started as a service (TCC /N)."


I can't find more info to this in the help. How can I use "TCC /N"?

It's not intended for general use. If you're running TCC as a service, you can add the /N option to notify TCC that it's a service. The only thing it affects is to ignore a CTRL_LOGOFF_EVENT if TCC is a service.

 

[vefatica]

It's not intended for general use. If you're running TCC as a service, you can add the /N option to notify TCC that it's a service. The only thing it affects is to ignore a CTRL_LOGOFF_EVENT if TCC is a service.

I'm curious now. I have a mail server, started by the AUTOEXNT service, running in UI0 (on the services desktop). If I send a certain email through the server, it will start a TCC (as NT_AUTHORITY on that desktop). Will a logoff cause that instance of TCC (started without "/N") to receive CTRL_LOGOFF_EVENT and therefore terminate?

 

[rconn]

I'm curious now. I have a mail server, started by the AUTOEXNT service, running in UI0 (on the services desktop). If I send a certain email through the server, it will start a TCC (as NT_AUTHORITY on that desktop). Will a logoff cause that instance of TCC (started without "/N") to receive CTRL_LOGOFF_EVENT and therefore terminate?

Yes.

A logoff of any user will send CTRL_LOGOFF_EVENT to all console processes on the system.

 

[Steve Fabian]

Yes.
A logoff of any user will send CTRL_LOGOFF_EVENT to all console processes on the system.

You mean that if a user logs off, not only the console processes of that user receive the CTRL_LOGOFF_EVENT, but also all other users' console processes? Is there a way for a console process receiving CTRL_LOGOFF_EVENT to discern that it is from another user's logging off?

 

[rconn]

You mean that if a user logs off, not only the console processes of that user receive the CTRL_LOGOFF_EVENT, but also all other users' console processes?

That's what I mean.

Is there a way for a console process receiving CTRL_LOGOFF_EVENT to discern that it is from another user's logging off?

No.

 

[vefatica]

Is it any different for WM_[QUERY]ENDSESSION (ENDSESSION_LOGOFF), which should be floating around at about the same time as CTRL_LOGOFF_EVENT? I don't thing those can cross desktops. How does TCC respond to them?

 

[rconn]

Is it any different for WM_[QUERY]ENDSESSION (ENDSESSION_LOGOFF), which should be floating around at about the same time as CTRL_LOGOFF_EVENT? I don't thing those can cross desktops. How does TCC respond to them?

Console apps don't see those messages.

TCC kludges around the WM_ENDSESSION problem by creating a hidden window that looks for WM_ENDSESSION, and runs TCEXIT before shutting down.

 

[vefatica]

Console apps don't see those messages.

TCC kludges around the WM_ENDSESSION problem by creating a hidden window that looks for WM_ENDSESSION, and runs TCEXIT before shutting down.

But TCC has had a (top level) window for a long time (hasn't it?). Is it not enough to handle the ENDSESSION_LOGOFF lParam and not bother with CTRL_LOGOFF_EVENT?
I had thought you used TCC's window for more than that.

 

[rconn]

Is it not enough to handle the ENDSESSION_LOGOFF lParam and not bother with CTRL_LOGOFF_EVENT?

No. It's not possible to prevent a logoff or shutdown when an app gets a WM_ENDSESSION message; just to delay it slightly while doing some cleanup. (Remember that 5 second timeout before the app is killed by Windows regardless of what it's doing.)

And Windows will send the CTRL_LOGOFF_EVENT anyway to the console app's event handler, and kill it if it doesn't respond appropriately.