A maior parte da pergunta aqui colocada é bem respondida aqui então eu não vou cobrir o velho terreno agora.
for services that do not run as svchost.exe, what is it that differentiates them from other non-service processes?
A única coisa que torna um serviço diferente de qualquer outro processo é que ele permanece aberto para responder a algo. Não há nada diferente sobre eles, mas isso significa que eles geralmente têm certas características. Eles geralmente são aplicativos CLI porque geralmente não precisam (ou querem) uma GUI. Eles também podem ser DLLs se um processo de host for destinado a gerenciá-los (como o svchost.exe); em geral, uma DLL é um código que não possui um ponto de entrada (o que significa que não pode ser executado diretamente, mas um programa pode carregá-lo na memória e executar o código).
Para explicar isso melhor, precisamos introduzir um novo termo, threads. Um processo pode gerar novos segmentos. A principal coisa a ser entendida sobre os encadeamentos é que cada encadeamento obtém seu próprio ponteiro de execução e age como um processo dentro do processo pai. O svchost.exe é um processo com o qual você pode registrar um serviço. Quando você fizer isso, o serviço será executado como um thread dentro do processo svchost.exe. Outra coisa importante para entender sobre threads é que eles não aparecem no Gerenciador de Tarefas (apenas o processo pai faz).
Na verdade, existem duas instâncias do svchost.exe em seu sistema. Um é um processo de modo de usuário e o outro é de propriedade do SYSTEM. A cópia SYSTEM permite serviços que são executados antes que alguém efetue login (que é algo que a maioria dos serviços desejará poder fazer).
Para que o svchost.exe saiba o que fazer com um serviço, ele deve ser capaz de agir como uma DLL. Isso significa que ele precisa implementar o DLLMain. Além disso, ele também deve ter um método HandlerEx que responda aos eventos que o svchost.exe aciona (SERVICE_CONTROL_STOP, SERVICE_CONTROL_SHUTDOWN, SERVICE_CONTROL_PAUSE, SERVICE_CONTROL_CONTINUE, SERVICE_CONTROL_INTERROGATE).
Se o serviço tiver implementado esses, ele simplesmente precisará ser registrado com svchost.exe para que ele saiba disso. Isso é feito com os aplicativos sc.exe e installutil.exe .
Agora que expliquei como tudo funciona, devo mencionar que muito disso está obsoleto nas versões mais recentes do Windows. Acredito que a abordagem atual sugerida é para os desenvolvedores de serviço também criarem seu próprio processo de host (seu próprio svchost.exe). Isso ocorre porque o svchost.exe tem sido o esconderijo perfeito para malware desde a sua criação. A maioria dos usuários não tem idéia de como reg \ unregar serviços com svchost.exe e apenas saber como vê-los (o gerenciador de serviços).
Por não permitir que os desenvolvedores se conectem ao svchost.exe, isso significa que eles devem criar um novo processo para seus serviços, o que significa que esse novo processo será exibido no gerenciador de tarefas. Ainda assim, acredito que, mesmo nas versões mais recentes do Windows, o método antigo de usar sc.exe ainda funcionará para compatibilidade com versões anteriores. Considerando que os usuários do Windows ainda estão lidando com erros que existem desde o DOS, eu imagino que ainda será possível por um longo tempo. Oficialmente, o svchost.exe é apenas para serviços do Windows agora.