Services2 - File-system plugin to list and manage services

[Dalai]

Hi there

I've written my first file-system plugin and just published it on totalcmd.net.

At the moment it is still in beta state, but it is quite stable.

What is Services2?

• It's a file-system plugin that can list, control and manage services registered in the local or remote system. It runs on Windows 2000 and later, both 32 and 64 bit systems.
• It is an alternative to the existing Services plugin (Version 2.4) written by Serge Kandakov (KaSA).

What are the advantages over Services 2.4?

• Unicode capable (this should be implemented correctly).
• 64 Bit version of this plugin to use in Total Commander x64.
• Translation to other languages possible (Chinese, Danish, Dutch, German, Hungarian, Italian and Russian are included in the package).
• Support for custom columns, including default view.
• Additional startup type "Automatic (Delayed)" on Vista and higher.
• Analyze service executables with internal and external tools (version 0.5.0 or higher)
• Manage services on remote systems (version 0.6.0 or higher)
• Show service PIDs (process IDs) (version 0.8.0 or higher)
• and many more (see totalcmd.net for an almost complete list)

More screenshots can be found in this gallery, including Service properties dialog, Custom columns view, Plugin settings and "File" download (F3 on a service).

[Edit 2021-10] A simple download mirror is now available, just in case totalcmd.net is down. [/Edit]

Please feel free to test it, comment, discuss, report bugs and so on .



If you want to make a translation of this plugin to your own language:

1. Make a copy of "English.lng" to "<your_language>.lng". Be sure to use the language's English name for the file name!
2. Open "<your_language>.lng" in your favorite editor. The .lng files should be encoded in Unicode (UTF-16), so please make sure to use an editor with Unicode capability.
3. Translate all strings. Please ensure you don't have duplicate keyboard shortcuts for labels, buttons etc. within the same dialog.
4. Add the language's name in the native language to section [Language].
   (optional) Add your name, nick and/or the date of the translation to section [Language].
5. Repeat steps 2 and 3 with pluginst.inf and Services2.lng (custom columns). Note: These two files should be encoded in ANSI.
6. Send the new language files to the e-mail address mentioned in the Readme, or post a link to the file in this thread.

Regards
Dalai

[MVV]

I think elevation support is a must-have for such plugin: if TC has no admin rights (or it is not elevated), plugin should start elevated admin tool that sets service parameters...

[Dalai]

Yes, in general you're right. But how am I supposed to do that? TC's command line parameters only allow to enter plugins (not to control them) and I don't know the command line parameters for TC's admin tool... and I don't think it's possible with it. If you know a (simple) way, let me know.

Ah, now I get it: I should write my own admin tool for such tasks, right? I will think about that.

Regards
Dalai

[MVV]

Yes, you should write your own admin tool that will connect pipe opened in TC process by your plugin, and then it will accept and execute commands that your plugin sends to it.
It requires some work of course but it worths it.

Elevated process may be started using ShellExecute with verb "runas". Admin tool may stay active until pipe is opened so it will close with TC, or after some inactivity time.

[Sir_SiLvA]

I think elevation support is a must-have for such plugin: if TC has no admin rights (or it is not elevated), plugin should start elevated admin tool that sets service parameters...

NO, NO and NO

If TC is NOT startet as Admin, a plugin should NEVER be able to elevate itself
(and I seriously hope Chris prevents that in the name of security....)

@Dalai: thanks for the work havent tried it yet, but why is it called Services2 when it actually has to be called Services3

Service-Plugin 1 was written by

Code: Select all

      CompanyName: None
      FileDescription	: Services
      FileVersion	: 2, 4, 0, 214
      InternalName	: Services
      LegalCopyright	: Copyright © 2002-2004 by Serge Kandakov
      OriginalFilename	: Services.wfx
      ProductName	: Services plugin for Total Commander

Service-Plugin 2 was written by

Code: Select all

      CompanyName: Jerry home
      FileDescription	: Service plugin for Total Commander
      FileVersion	: 1.0.0.0
      InternalName	: TC Services.wfx
      LegalCopyright	: Copyright (C) 2003-2005 by Jerry
      OriginalFilename: TC Services.wfx
      PrivateBuild	: 1.0.0.0
      ProductName	: TC Services
      ProductVersion	: 1.0.0.0

Edit: at first look - why provide an example ini making one think you store data in same directory as plugin is (what i prefer over anything else) when the Plugin itself shows %commder_path%\fsplugin.ini as storage place of ini settings?

[MVV]

Sir_SiLvA, plugin doesn't elevate itself, it just asks you to perform elevated operation (and you'll see elevation dialog anyway), just like when you're e.g. trying to copy file to C:\Windows.
And it is obviously much better way of doing things than starting elevated TC instance just to be able to manage services (or searching files via Everything, or editing registry, or anything else that requires elevation).

BTW there is no way for plugin to elevate itself, Windows doesn't support elevating separate threads or modules.

[Dalai]

@Dalai: thanks for the work havent tried it yet, but why is it called Services2 when it actually has to be called Services3

Service-Plugin 1 was written by

Code: Select all

      CompanyName: None
      FileDescription	: Services
      FileVersion	: 2, 4, 0, 214
      InternalName	: Services
      LegalCopyright	: Copyright © 2002-2004 by Serge Kandakov
      OriginalFilename	: Services.wfx
      ProductName	: Services plugin for Total Commander

Service-Plugin 2 was written by

Code: Select all

      CompanyName: Jerry home
      FileDescription	: Service plugin for Total Commander
      FileVersion	: 1.0.0.0
      InternalName	: TC Services.wfx
      LegalCopyright	: Copyright (C) 2003-2005 by Jerry
      OriginalFilename: TC Services.wfx
      PrivateBuild	: 1.0.0.0
      ProductName	: TC Services
      ProductVersion	: 1.0.0.0

There is

• TC Services (it's really called that)
• Services (Version 2.4) (there was a version 1.x of this plugin according to its readme.txt)
• and now there is Services2 which is a "descendant" of Services.

However, I thought quite a while about the plugin's name (Services2, Services64, ServiceManager and so on) but didn't come up with a better name yet. If you do have a better name, feel free to post it here .

Edit: at first look - why provide an example ini making one think you store data in same directory as plugin is (what i prefer over anything else) when the Plugin itself shows %commder_path%\fsplugin.ini as storage place of ini settings?

Uh, no. Services2 stores its settings in fsplugin.ini, which is stored where wincmd.ini is located. If TC is installed on Vista or higher, wincmd.ini is - by default - stored in %AppData%\Ghisler (IIRC) - so fsplugin.ini defaults to %AppData%\Ghisler\fsplugin.ini on Vista and higher. The Services2.ini.sample is there to give the user an easy starting point for making the plugin portable (or store its settings in plugin directory which I prefer, too). I know, it looks a bit "out of place" to use fsplugin.ini if it's stored in %COMMANDER_PATH% but that's how it is, as it's the proper location on Vista and higher.

Furthermore it's not recommended to provide <pluginname>.ini because of probable update problems - see first post of this thread.

Regards
Dalai

[Dalai]

Yes, you should write your own admin tool that will connect pipe opened in TC process by your plugin, and then it will accept and execute commands that your plugin sends to it.

Are you sure the plugin should open the pipe? What about multiple plugin instances?

I've written another program that uses pipes some time ago where I used unit Pipes by Russell Libby. That unit contains TPipeServer and TPipeClient (and TPipeConsole which isn't relevant here).

I fiddled about with this unit and now I'm confused where to use which component. Let's assume the plugin opens the pipe (using TPipeServer) and the admin tool connects to it (using TPipeClient). As long as there is one plugin instance all is well. A second plugin instance could open another pipe instance but the client (admin tool) listens only on the first instance (and switches to the second one if the first one is closed). I hope you can understand the problem.

Wouldn't it be better to do it the other way around: the admin tool opens the pipe and all plugin instances connect to it as clients? I know that I would have to wait in the plugin until the pipe is created.

Any advice and/or ideas?

Thanks and regards
Dalai

[MVV]

AFAIK it is impossible for non-elevated process to initiate communication with elevated one via pipe: it would be a security hole. That's why admin instance should do it.

There shouldn't be multiple instances within same TC installation. Anyway you may simply start one admin tool per plugin instance, just like TC does.

[Dalai]

AFAIK it is impossible for non-elevated process to initiate communication with elevated one via pipe: it would be a security hole.

Interesting, because that's exactly what TC seems to do. I've looked at the imports of TC's files and only tcmadmin.exe imports CreateNamedPipe, totalcmd.exe doesn't.

Anyway you may simply start one admin tool per plugin instance, just like TC does.

At first, I've tried to avoid this, but maybe it's easier this way.

Regards
Dalai

[MVV]

If you look at TCMADMIN command line, it seems that TC passes pipe identifier like 2128 and machine id. And, in handles you can find opened file like \Device\NamedPipe\TcPipe2128.

At first, I've tried to avoid this, but maybe it's easier this way.

I think every TC instance's plugin should ask for elevation anyway, so it is OK.

[Dalai]

If you look at TCMADMIN command line, it seems that TC passes pipe identifier like 2128 and machine id.

Yes, I've seen that, but I'm not sure it's only the pipe identifier. From what I've been able to determine, it's the PID of the current TC process, so tcmadmin.exe knows which pipe to open (which then of course has TC's PID appended). The second parameter is the fully-qualified account name, which I guess tcmadmin uses to set the security descriptor before opening the pipe (to avoid opening a security hole).

Regards
Dalai

[HAL 9000]

disregard this (or please delete)

[Dalai]

@HAL 9000: Are we talking about the same plugin? There are no events in Services2, nor are there any warnings, errors and so on.

And, multi-sorting is supported in custom columns as well as in details view mode, of course. I just tested it again successfully. TC does the sorting, the plugin hasn't to do anything special to make it work.

Regards
Dalai

[petermad]

Danish translation of Services2 v. 0.4.0 kan be downloaded here: http://madsenworld.dk/tcmd/wfx_Services2_0.4.0_dan.zip