This paper compares the architectural design of UNIX and Windows operating systems across four key dimensions: kernel architecture, application programmer interfaces (APIs), security models, and process management. The analysis examines how UNIX's monolithic kernel differs from Windows' hybrid kernel in terms of customizability, reliability, and developer preference. It also explores divergent API strategies, contrasting authentication and permission models, and the role of shell scripting in UNIX process management. The paper concludes that while both operating systems support enterprise-level workloads, the choice between them ultimately depends on the specific technical and organizational requirements of the deployment environment.
Microsoft Windows and UNIX operating systems have achieved significant adoption in enterprises globally, based on their proven reliability in demanding computing environments and their ability to scale in support of complex transactions and network workflows (Maurno, 2005). This analysis evaluates the UNIX and Windows operating system architectures on the basis of differences in their kernel architectures, application programmer interfaces (APIs), security, and approaches to process management. Both operating systems support shell scripting, though this approach to process management and exception handling is more prevalent on the UNIX platform (Takeuchi & Nakayama, 2006).
The design of each operating system's kernel is significantly different, varying in how each supports I/O management, memory management, scheduling, power management, and thread management. One of the most significant differences between the kernels of these operating systems is how each defines and uses subsystems for completing application development while supporting deployment and delivering a high level of reliability at the system level (Janssens, Annot, & van de Goor, 1986). The UNIX operating system's architecture is divided into three levels, with the lowest — or most fundamental — level being the kernel, which is responsible for scheduling tasks, managing resources, and controlling all aspects of operating system security (Hontanon, 1999). One of the most significant differences between the UNIX and Windows operating system architectures is that the former recompiles the system-level kernel at runtime. Database developers have favored the UNIX platform as a development environment as a result of this feature, as it makes troubleshooting application development much more accurate and efficient (Son, Lee, Jeon, Chung, Lee, & Lee, 2011). Conversely, the kernel architecture of the Windows operating system does not recompile and is not as customizable as the UNIX kernel.
Another variation in kernel architectural design that directly affects how customizable both operating systems are is the design philosophy regarding monolithic versus hybrid kernels (Zhou & Goscinski, 1997). The UNIX operating system kernel is considered monolithic in that it supports the main operating system services, including the main kernel thread that defines the use of memory. Developers prefer to code on platforms with monolithic kernels when there is intensive use of device drivers, system resources, and a need for advanced memory management and file management (Zhou & Goscinski, 1997). A monolithic kernel also contains all device-level intelligence, which becomes a reliability concern if a device driver fails — such a failure can cause the entire system to crash. The Windows operating system architecture is designed with a hybrid kernel, allowing for greater customization and modularity, including the ability to significantly change application performance through API calls.
There are also basic foundational differences in how the Microsoft Windows and UNIX operating system architectures are designed, each following a completely different philosophy with regard to support for application development, security, and long-term reliability (Maurno, 2005). While there are many variations of the UNIX architecture, they all share three levels of functionality in common, including having the kernel at the lowest level. The kernel — which is monolithic in that it supports all resource- and memory-based sharing tasks — also manages all security tasks, including the secure scaling of the operating system across multiprocessor environments (Janssens, Annot, & van de Goor, 1986). This aspect of the UNIX kernel has continued to gain importance as enterprises look to scale their databases and applications across broad geographical and system-based resources (Son et al., 2011).
At the next level of the UNIX architecture is the shell, or user interface, which is used for interpreting user commands and starting applications. This is the level at which UNIX system administrators spend the majority of their time writing shell scripts for managing processes. A sample shell script is provided in the Process Management section of this paper as an example. At the third level of the UNIX operating system architecture, tools and command utility functions are supported. As the kernel is the foundation of the UNIX operating system, it must scale to support all of these functions and also track memory and resource usage over time.
In contrast to the monolithic nature of the UNIX kernel, the Microsoft Windows operating system kernel is more hybrid in design, comprised of a series of modules. Microsoft chose to create a hybrid-based kernel architecture because this type of kernel supports faster development times for drivers within the modules themselves — no reboot is required if only a module of the operating system is being updated. This represents a lesson learned from UNIX kernel development that Microsoft chose to deliberately emulate at the module level. Microsoft has also designed its subsystems to offer a greater variety of APIs for supporting specific function calls, which further streamlines this operating system's integration into networked environments (Iyer, Lee, Venkatramen, & Vesset, 2007).
The Microsoft hybrid kernel approach is also designed to allow greater support for faster and more secure integration with third-party platforms through a wide variety of network protocols, including TCP/IP, DHCP, XML, and TELNET sessions as defined in UNIX shell scripts (Vellalacheruvu & Kumar, 2011). Unlike UNIX, the kernel mode in Windows is designed for rapid performance and ease of integration with third-party computing environments. Microsoft chose to place the Logon Process, Win32 application, Interix/POSIX subsystem, Win32 subsystem, and Security Subsystem in the User Mode of their operating system architecture to make them more agile and less constrained by kernel-mode limitations. Microsoft began setting security as a strategic design priority during the 2001 and 2002 development cycles, and this architecture allowed for complete revisions and updates to the Security Subsystem as needed to keep the technology current against emerging threats (Vellalacheruvu & Kumar, 2011).
In analyzing the differences between UNIX and Windows at the subsystem level, Microsoft's inclusion of subsystems for Win32, POSIX, and Windows Services for UNIX in User Mode allows for greater customization to specific enterprise users' needs. Microsoft designed Windows Services for UNIX to support 300 different UNIX commands, including KornShell, C Shell, and common commands such as awk and the text editor vi. The high degree of modularity of the Microsoft Server architecture is easily customizable, yet it also presents security risks, which are examined in the security section of this analysis (Hartley, 2008).
In UNIX, API commands and syntax are often referred to as system calls. A system call is a procedural command into one of the modules of the monolithic kernel and is typically used for changing device parameters or enabling integration with third-party devices and functions. UNIX APIs vary significantly across releases and have also begun to proliferate across Linux operating system distributions. APIs in UNIX are most effective when programmed at the kernel level to ensure optimal performance of application software and system modifications. As a result, APIs in UNIX often impact overall system performance across all devices and can either drastically improve or degrade total application and server performance depending on the quality of programming completed (Iyer et al., 2007). This is especially evident in database development and programming on the UNIX platform (Son et al., 2011).
The Microsoft API strategy is fundamentally different and focuses on creating emulations of different operating system kernels. In the Microsoft architecture, kernels are also located at the User Level, which makes their APIs more efficient and customizable through tailored development. As a result of this design philosophy, the Windows architecture supports subsystem APIs for its native Win16 and Win32-based applications, in addition to support for UNIX (POSIX) systems with a series of APIs that emulate UNIX commands.
"Authentication models, permissions, and Active Directory"
"Multithreading, GUIs, and UNIX shell scripting"
Comparing UNIX and Windows operating system architectures on the variations in their kernel architectures, application programmer interfaces (APIs), security, and approaches to process management illustrates how vastly different the design and development philosophies of each of these systems are. UNIX has a strong legacy in the scientific and engineering community, and the level of customization available at the kernel level reflects how deeply supported and adaptable this operating system is. Windows' architecture is more focused on ease of customization and support for a broader base of integration, a priority that Microsoft appears to have derived from its enterprise customers — organizations managing hundreds of legacy systems they need to use in conjunction with Windows.
You’re 60% through this paper. Sign up to read the remaining 2 sections.
Sign Up Now — Instant Access Already a member? Log inAlways verify citation format against your institution’s current style guide requirements.