>
Windows under the hood is VERY UNIX like.That's a comparison that comes with a lot of caveats. The timeline of Windows NT versus things like the IBM System Resource Controller and the Solaris Service Management Facility is one such. Another is that it really depends from which Unix; even setting aside the fact that systemd only runs on Linux, not Unix. There are some significant structural differences, moreover.
* On AIX, the program that runs as process #1 is init, processing inittab and handling runlevels. Service management is done by another program (srcmstr) running as a separate process; which client programs send commands to via /dev/SRC, a local domain socket. Terminal login is not considered to be a service to be managed as other services are, and is spawned by init not by the SRC.
* On Solaris, there is an init program that runs as process #1, handling runlevels. The SMF master restarter (svc.startd) and configuration manager (svc.configd) programs run as separate processes; instructed by client programs such as svcadm and svccfg. Terminal login (as of Solaris 11) is considered to be just another service managed by the SMF, an instance of svc:/system/console per terminal.
* On Linux or FreeBSD/PC-BSD running nosh, there is a system-manager program that runs as process #1, handling system state. A service-manager to supervise services runs as a separate process. Commands such as service-control and system-control communicate with with them via FIFOs and files in the filesystem. Terminal login is considered to be just another service managed by the service manager, one ttylogin@ttyN service per terminal.
However:
* On Windows NT, the first user process runs the Session Manager program (SMSS.EXE). Services are managed by another process running the Service Controller (SERVICES.EXE). Client programs send commands to the Service Controller and to the Session Manager using "Native API" LPC; the former to manage the supervision of services and the latter to do things that don't really have a Unix/Linux equivalent like turn on the POSIX subsystem in a session. Terminal login is not managed by either the service manager or the system manager, but by the WINLOGON and Local Session Manager programs, and is not treated as anything like a service.
Furthermore:
* On Linux running systemd, there isn't the dichotomy as in the aforementioned systems. System and service management are both done in one program, running as process #1, not in two separate ones. There isn't one direct control/status API, either. The process #1 program exports a Desktop Bus interface, which requires that a Desktop Bus manager daemon be running. To avoid the chicken-and-egg problem that results (since the Desktop Bus daemon is a service that is managed by the process #1 program), there's a separate, private and intentionally undocumented, "bus" API directly to the process #1 program. This is "known" only to the systemctl program. There's also a handshake between the process #1 program and the Desktop Bus manager daemon, activated by its largely undocumented --systemd-activation option, whereby the latter tells the former when there's a Desktop Bus for it to register its API with. Terminal login is a service managed by the mixed-together service/system manager, an instance of the autovt@.service service per terminal, with activation of these terminal login services controlled by another service, systemd-logind.