So there is this small OS called Windows.
It has this rather old and complex API to develop applications upon. Dating back to Windows 1.0 and being for the most part forward compatible to Windows Vista. This path of course took a miandering route through Windows 3.x, Windows NT, Windows 95, 98, and the dreaded ME (Freud eat your heart out). Picking up steam with Windows 2000, Windows XP, and Windows 2003. A core API has existed through 16Bit to 64Bit, single cpu to quad core, 1Mb to 3Gb of ram, and Token ring to Wifi.
Obviously this API is a bit crufty. Microsoft recognizes this, but places a large effort internally to maintain a certain level of backwards compatibility. While Raymond Chen is not an official voice of Microsoft (as stated daily by himself), his tidbits about challenges faced in bringing abusing and poorly written third party applications in line for a major OS upgrade are amusing and insightful.
Now after understanding all the cruft that goes into an OS upgrade, and all the API’s that are locked in place, possibly patched at runtime just to bring as much software as possible into the new version, consider where the API is on Linux.
How much of the OS depends on a loose connection over a command line and batch script? How many tools do you use that are installed, services started, stopped, restarted, monitored, and removed all from command line scripts?
Now think about the your interface to the OS. Are you going to open a file manager to track down that run away process, or are you going to turn to a shell to find that application via ps -A | grep <filename that may not be human readable, and hope to god it doesn’t contain a space>. All the cruft is Win32 API, is sitting right there in your command prompt to comply with POSIX, and all the archaic systems out there doing backups to tape using tar.
Ewww?