Main Area and Open Discussion > General Software Discussion
Replacing the Control Panel
Vurbal:
Okay, here's an easier question if only to prove I actually have those from time to time. :P
What are some simple command lines that would be good to have handy to have available on a basic system menu? Mostly I'm thinking about basic maintenance tools which don't need any user input. The first one that came to mind was the System File Checker (sfc /scannow). I'm sure there are others but nothing comes immediately to mind.
Power user commands or tools (the kind most users shouldn't touch in the first place) will also be getting their own submenu. Or maybe even just a separate base menu altogether that's not visible by default. Suggestions along those lines would also be useful.
For right now I'm going to rebuild the LBC configuration and then I'll post some screenshots to provide some context for what I'm doing.
oblivion:
What are some simple command lines that would be good to have handy to have available on a basic system menu?
-Vurbal (August 16, 2013, 11:40 AM)
--- End quote ---
Have read all this with a combination of amused fascination and horror. You, sir, are a brave man. :)
Is chkdsk <driveletter> /f worth including?
Something I'd find useful -- a way to get at some of the control panel stuff when the logged-in user is restricted but I have an admin password I can run stuff as.
In these situations, I generally do runas /user:<whatever> cmd.exe and then try to remember which of the .cpls do what (control.exe whatever.cpl) since they're almost completely impossible to identify function from name. (If you don't already know, you'll never guess what main.cpl is for!) So something along the lines of what you're doing I could run from a stick and that I could fire an admin account at without having to log the user off -- now that'd be really useful :)
Vurbal:
What are some simple command lines that would be good to have handy to have available on a basic system menu?
-Vurbal (August 16, 2013, 11:40 AM)
--- End quote ---
Have read all this with a combination of amused fascination and horror. You, sir, are a brave man. :)
-oblivion (August 19, 2013, 02:08 AM)
--- End quote ---
Thank you, but I suspect it's more foolish than brave. :huh:
Is chkdsk <driveletter> /f worth including?
--- End quote ---
It's actually one of the options I've been considering but I need to figure out a way to do it in a way that it doesn't require the user to select the drive. For the drive with the Windows folder it should be as simple as using %SYSTEMDRIVE% for the drive letter. That's assuming I can work out a suitable method for entering the proper credentials dynamically as well. (more details below)
A better option would be to come up with a method for parsing the list of drives, isolating the hard drives, and presenting an option for each on the menu with a format like Check drive VolumeName [X:] for errors. It would be complicated but definitely something LaunchBar Commander should be capable of using its dynamic menu features.
Something I'd find useful -- a way to get at some of the control panel stuff when the logged-in user is restricted but I have an admin password I can run stuff as.
In these situations, I generally do runas /user:<whatever> cmd.exe and then try to remember which of the .cpls do what (control.exe whatever.cpl) since they're almost completely impossible to identify function from name. (If you don't already know, you'll never guess what main.cpl is for!) So something along the lines of what you're doing I could run from a stick and that I could fire an admin account at without having to log the user off -- now that'd be really useful :)
--- End quote ---
I've been toying with a couple ideas for launching items using alternate credentials. The RunAs command should do the job, but it would require coming up with a way to prompt for at least the username. That's based on memories from my WinXP sysadmin days so I could be remembering wrong or it may not work the same now.
Assuming the basic idea is sound, the next question is how to get credentials from the user. The simplest way would be a batch file or a script of some kind (WSH or PowerShell) but I'd rather not go that route for a number of reasons. There's a tool I've found which I suspect can do the job but it's a little (or a lot) over my head at the moment. More on that in a future post.
I'm also concerned about an oddity I ran into for launching the Windows Features tab directly - ie not from inside the Programs and Features applet. I posted it on the LBC forum:
Problem: Unable to get the Windows Features Control Panel to populate when launching it directly using the following rundll32.exe command:
rundll32.exe shell32.dll,Control_RunDLL appwiz.cpl,,2
Solution: After a bunch of testing it appears the problem is in rundll32.exe itself. Populating the list of features is actually done by TrustedInstaller.exe which can only be run by the built-in System account. System fails to create the svchost.exe process to do this if rundll32.exe is launched by any process besides explorer.exe (via the Run dialog) or cmd.exe (directly from the command prompt). I ran into the same problem attempting to launch it indirectly from the command prompt using NirCmd's exec feature.
As an alternative it can be launched using the built-in alias of optionalfeatures. Technically it's optionalfeatures.exe, but it only seems to work in LBC if I leave off the .exe file extension and doesn't even work with that syntax when launching via NirCmd exec.
--- End quote ---
The continued use of main.cpl for the Mouse applet is a perfect example of why Windows is such a mess. Whatever the specifics, improvement is change. If you prioritize minimizing change ahead of improvements, as Microsoft always has, you end up with kludges instead of fixes. When you start building on kludges you end up relying on even more kludges until eventually they're the rule rather than the exception.
In the case of today's Windows that goes all the way back to the core Windows NT architecture. Compatibility with DOS-based (Win9x) code required a tangled mess of kludges. Eventually Windows either needs a complete reboot (no pun intended) like Apple did with OS X or it's not going to be around in the not too distant future.
For my part I've decided to ignore the gaping hole in the Titanic's hull and focus on rearranging the deck chairs. :-\
Vurbal:
Project Update:
Although I'm sticking with my broader plan in the long term, I've decided my earlier strategy of using smaller steps was the right one. In fact I'm actually going to simplify a little further for the first stage and start by just transferring core Start Menu functionality to my System Bar almost entirely as-is. That leaves me with 4 menus at the moment:
* Power: Logoff, shutdown, lock computer, and screensaver options via NirCmd.
* Command: Run, Search, Windows Explorer from the Start Menu plus a few additional nodes like Eject Device (safely remove hardware), and Volume Control along with a handful of other features provided by NirCmd. At a minimum that will include Mute/Unmute system volume, Empty Recycle Bin (NirCmd), and Refresh explorer and environment (shellrefresh / sysrefresh).
* Programs: LBC's %AllStartMenu% virtual folder menu copied from the example launchbar.
* User Files: Some combination of submenus from the MRU (Most Recently Used) plugin and the user profile special folders such as My Documents. I'm completely undecided about which items to include or not.
That still leaves the Control Panel as an open question. The example launchbar has a My Control Panel menu which covers the basics but isn't really sufficient by itself. Ideally I'd be able to simply use a shell virtual folder - shell:::{GUID} - to populate the menu. That could duplicate the Start Menu's menu view option but it's only supported for LBC's specific list of virtual folders. That's actually an improvement over most launchers.
That leaves leaves just a couple options. The simplest would be just adding a Control Panel (command) node to open it normally. I could supplement that with another command node to open the All Tasks (aka GodMode/Master Control Panel) view using explorer.
Alternatively - or even additionally - I could build a menu of Control Panel applets equivalent to the Start Menu's 'View as menu' option. The big advantage to that approach is the flexibility to hide items most people never need to see like Anytime Upgrade and CardSpace. In fact it would be easy to hide the menu entirely. The disadvantage to such a menu is that third party Control Panel applets wouldn't appear automatically. However those should be available as regular programs (from the Start Menu) anyway.
That leaves the question of using control/rundll32 for launching them vs shell virtual folders. The only real advantage I see to the first method is access to individual applet tabs. For just opening the basic applets I'm leaning toward the explorer method.
The Next Step(s)
Once I have the basics transferred to LBC I can focus on more specialized menus. The basic focus will be on replacing the Control Panel and (Start Menu) Programs options. That will include replacements for some Control Panel applets and probably also the control/rundll32 options for opening individual applet tabs. The other thing I'd like to figure out is how to get away from the actual Programs folders used to generate the Start Menu. I've had too many bad experiences with shortcuts mysteriously disappearing. That's besides the basic problem that programs without installers don't put shortcuts there to begin with.
It's simple enough to add programs to LBC but separating the programs you want to launch from various helper exe's can be indistinguishable from magic. If I could find a way to semi-automate that process and create a text file in a format supported by LBC it would be a huge improvement. It's obviously not nearly as simple as that makes it sound - but that's why it's a challenge.
While visiting the website for one CP applet alternative I've already tried (7+ Taskbar Tweaker) I actually ran across another program I'd forgotten about. The same developer (RaMMicHaeL) wrote a cool little program for running WinAPI functions as commands. It's called winapiexec. If I was an actual programmer I suspect I could solve most of my problems with it.
Then again if that were the case I could write programs to do it right. :)
Vurbal:
So here's the latest on my *little* project. First I've decided to add just one or 2 more items to the first phase. Due to the clumsiness of replacing the Start Menu search box with the full blown Windows Search GUI I'm going to jump right into using FARR as a replacement. Besides the minimal size, it has the advantage of having a plugin to use the Windows search index and also launch files, making it something of a replacement for the Run dialog as well. I may also mention Everything since FARR has a plugin for its index as well.
I've also come to the conclusion I really need to learn AutoHotkey because it seems to be the simplest way to integrate basic Windows dialogs and controls.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version