Most of the question posed here are answered fine here so I'm not going to cover old ground now.
for services that do not run as svchost.exe, what is it that differentiates them from other non-service processes?
The only thing that makes a service different from any other process is that it remains open in order respond to something. There is nothing else different about them but this does mean that they often have certain characteristics. They are usually CLI apps because they generally don't need (or want) a GUI. They can also be DLLs if a host process is meant to manage them (such as svchost.exe); very generally speaking, a DLL is code which doesn't have an entry point (meaning it cannot be ran directly but a program can load it into memory and run the code).
In order to explain this better we need to introduce a new term, threads. A process can spawn new threads. The main thing to understand about threads is that each thread gets it's own execution pointer and acts like a process within the parent process. svchost.exe is a process which you can register a service with. When you do that, the service will be ran as a thread within the svchost.exe process. Another important thing to understand about threads is that they don't show up in Task Manager (only the parent process does).
There are actually two instances of svchost.exe on your system. One is a user mode process and the other is owned by SYSTEM. The SYSTEM copy allows services which run before anyone logs in (which is something that most services will want to be able to do).
In order for svchost.exe to know what to do with a service, it must be capable of acting like a DLL. This means that it needs to implement DLLMain. Additionally, it must also have a HandlerEx method which responds to the events which svchost.exe fires (SERVICE_CONTROL_STOP, SERVICE_CONTROL_SHUTDOWN, SERVICE_CONTROL_PAUSE, SERVICE_CONTROL_CONTINUE, SERVICE_CONTROL_INTERROGATE).
If the service has implemented those then it simply needs to be registered with svchost.exe so that it knows about it. This is done with the applications sc.exe and installutil.exe.
Now that I've explained how it all works I've got to mention that much of this is deprecated in newer versions of Windows. I believe that the current suggested approach is for service devs to also create their own host process (their own svchost.exe). This is because svchost.exe has been the perfect hiding place for malware since its inception. The majority of users have no idea how to reg\unreg services with svchost.exe and only sort of know how to even see them (the services manager).
By not allowing devs to attach to svchost.exe it means that they must create a new process for their services which means that this new process will show up in task manager. Still, I believe that even in the latest versions of Windows, the old method of using sc.exe will still work for backwards compatibility. Considering that Windows users are still dealing with bugs which have existed since DOS, I'd imagine that it'll still be possible for a long time to come. Officially, svchost.exe is only for Windows services now.
