In CE 6.0, one of the things we changed was naming services.exe to be servicesd.exe.  I mentioned it at the end of my CE6 services.exe initial post as to why we did this.  Services.exe in CE6 is just a simple command line wrapper that lets you do things like "services stop HTP0:"; no longer does it do this OR host the service DLLs depending on whether it was the first services.exe started up on the system.

This change has nothing to do with the new kernel.  In fact, I could have justified this name change even had I not had to rewrite services.exe in the first place.  The first reason is to avoid confusion.  It's confusing to say "well, services.exe can host service DLLs or be the command line intepretter for the 'real' services.exe".  That wouldn't justify reworking the code though.  To justify that, it gets down to security.  See here for information about the particular security vulnerability, namely the CreateProcess("services","bad command",...) elevation of privelege trick.  (Note we didn't ship the devices like this, but disabled the functionality altogether.)

In the new world order, we don't have to worry about this because servicesd.exe will be a trusted process and it won't respond to random stuff doing CreateProcess("servicesd.exe",...) on it.  If an application does CreateProcess("services.exe","bad command") now services.exe is going to be the lowest trusted process class.  So when the service that is asked to do the bad command checks its caller, there won't be a potential for elevation of privelege.

[Author: John Spaith]