On Windows, firmware loads bootloader, bootloader loads ntoskrnl (NT kernel), ntoskrnl starts first user process smss.exe, smss starts security subsystem lsass.exe, lsass starts winlogon.exe, winlogon logs user on and starts the shell, explorer.exe
On Linux, bootloader loads vmlinuz (kernel), vmlinuz starts first user process (init), init starts display manager (eg gdm), gdm logs user on and starts another copy of the X server and launches user's favorite window manager.
These have essentially stayed the same since the first NT 3.1 release and Red hat 0.9. I'm not familiar with Mac OS X or other Unices but I imagine they aren't that different. Modern desktop OS design has essentially converged to a point where there is no fundamental difference between any modern desktop OSes, because after all they are all trying to solve more or less the exact same set of problems. When a user inserts a flash drive he expects it to be mounted automatically (you can't honestly expect most end users to type in a sudo command to access his flash drive, can you), and this in fact requires careful coordinations from a ton of system components to implement securely, because mounting a filesystem is a privileged operation (you certainly don't want the end user to be able to unmount the root filesystem do you, but he should be able to unmount his flash drive). This is why things like polkit are necessary. People in Linux land love to complain about dbus --- oh it's turning Linux into the big evil M$ Windowz --- but how do you propose to solve the problem of two talking processes having to send objects between each other? With plan9's 9p? How about authentication? How do I make sure the process I'm talking to is really the process I think it is? If you try to solve all these problems, you end up with something that's essentially no different from dbus.