CPL extension handling - 36.0.55 no longer works

[MPB]

Here's an odd situation. Sometimes I'm in the TCC window and I might just type "appwiz.cpl" or "timedate.cpl" to bring up the appropriate Control Panel applet. I noticed after trying 36.0.55 that it no longer works and I get an error "This file does not have an app associated with it..."

However it works fine in 36.0.52 for example, and I've used it this way a lot over the years.

If I run "ASSOC" I can see this with either version, so the .CPL is correctly associated as far as I can tell:
.cpl=cplfile

Other associations that I often launch from the TCC prompt are things like "services.msc" to launch that MMC, however in that case, I have a line in my TCStart.btm:
rem *** enable .msc files to be launched by mmc
set .msc=mmc.exe

It's just odd that the CPL thing has always just worked until 36.0.55. If that's by design, no worries, I'm sure I can add something like this to my startup batch... just tested, and it does indeed work:
set .cpl=control.exe

 

[vefatica]

It's a little odd. Supposedly, TCC knows what to do with it.

v:\> which appwiz.cpl
appwiz.cpl is associated with : C:\Windows\System32\control.exe

v:\> appwiz.cpl
TCC: (Sys) C:\WINDOWS\system32\appwiz.cpl is not a valid Win32 application.

*.msc work here and it's not an executable extension.

 

[rconn]

This is a chain of unfortunate events.

1. Microsoft deprecated .cpl files a while back.
2. In recent Windows updates, they've gone farther and removed the "open" verb from the .cpl associations.
3. TCC starts child apps in a job so it can manage them when you shut down a Take Command / TCC tab window.
4. When TCC runs a GUI app, it needs to tell it to break away from the job. This requires either passing the appropriate flag in CreateProcess, or running the app in an elevated process.
5. There are some badly-behaved Windows apps (from Microsoft) that don't work unless (a) they're run elevated, and (b) you don't pass the "break away from the current job" flag. For those, build 55 added a couple of workarounds, including one that told ShellExecute to use either "runas" (for an elevated app) or "open" (for non-elevated GUI apps).
6. .CPL files aren't recognized as either console or GUI apps, so TCC defaults them to the GUI behavior.
7. TCC tells Windows to run the app using ShellExecute with the "open" verb (which instructs Explorer to handle it using the value in the "open" key).
8. Although Windows knows how to execute the file, it refuses to do so because the "open" key has been removed.

I've added another workaround for the next build that checks for a .CPL extension, and uses the NULL value for the verb. If NULL is passed to Explorer, it happily associates the .CPL file with "control.exe".

 

[MPB]

That's awesome. In my case, the "timedate.cpl" thing from an elevated command prompt is more of a timesaver than anything. I have locked down rights on my system so if I want to change my timezone, for example, I can't just do it normally, I have to run timedate.cpl elevated. If I happen to already have a TCC window open that's already elevated, it's just a convenience factor. I do tend to run the add/remove programs applet via appwiz.cpl too, although that one I just run from the start bar most often since it'll prompt for elevation unlike the timedate.cpl... must be an oversight on Microsoft's part on that. :)

There are a lot of things that the Settings app does that control panel applets used to do, but there are still those occasional applets that don't have an equivalent Settings section. I guess if Microsoft really wants to move away from Control Panel, they better get busy and migrate the rest of those, but I'll miss the convenience of just running a quick CPL to get where I need to be.