In the face of the mass-media criticism of Windows Vista, mainly with regards to the performance issues present when compared to Windows XP on hardware with similar specifications, very little information has been presented with regards to the performance of Windows 7. This article, however, shall change that.
For Windows Vista, Microsoft had to change their design and development strategy in order to comply with the DoJ and EU regulations regarding the anti-trust issues present in previous versions of Windows; specifically, the integration of assistive applications such as Internet Explorer and Windows Media Player into the core operating system. Competitors complained that offering internet and media solutions with the operating system harmed competition in the marketplace (despite other operating systems such as Mac OS X and Linux apparently being immune from such criticism).
In response to this, Microsoft made fundamental changes to the way Windows Vista was linked together; shifting more towards modular designs rather than the monolithic processes used in previous versions of Windows. This increased amount of componentization, while satisfying the DoJ and EU, also led to performance issues due to the increased number of libraries which comprise the operating system. On traditional hard drives, the more separate files which the operating system has to load, the more seeking across the hard drive is required, and therefore overall performance takes a hit.
Another reason for Windows Vista’s performance issues is the way in which Microsoft approached backwards compatibility in Vista. The operating system stores multiple copies of core system libraries, as each revision of a library typically adds/removes functions, and applications compiled with dynamic links to a specific version of a DLL file may call on functions not present in the currently installed library. Vista aims to solve this issue through the WinSxS collection; essentially a massive store of every differing version of libraries present on the system. That way, when an application makes a call for a dynamically linked library, Vista queries the WinSxS cache for the correct version, which is then loaded into memory. On the average system, this directory can be several gigabytes in size, with much of the code duplicated between the separate versions many times.
Windows 7 takes a different approach to the componentization and backwards compatibility issues; in short, it doesn’t think about them at all. Windows 7 will be a from-the-ground-up packaging of the Windows codebase; partially source, but not binary compatible with previous versions of Windows. Making the break from backwards compatibility is a dangerous proposal but a dream for software developers. Performance of native applications can be increased, distribution sizes can be cut down, functionality can be added without the worry of breaking old applications, and the overall end-user experience can be significantly improved.
However, Windows’ lure has always been that applications from older versions of Windows are almost guaranteed to work post-upgrade; this is in contrast to older UNIX solutions where upgrading the system could render old applications useless without access to the source code. On an operating system which uses a binary distribution model, this is an unreasonable expectation. However, there is one company which made a success out of breaking backwards compatibility, using a method which Microsoft are seeking to emulate with the launch of Windows 7. The company in question is Apple.
During Apple’s death throes back at the start of the decade, Steve Jobs made a bold decision; to replace the old, proven Mac OS lineage with a UNIX-based platform running a custom GUI. The purpose of this was to offer potential customers a significant reason to switch to Apple’s hardware and software solutions. Mac OS X was such a success – despite breaking backwards compatibility – that many customers were willing to put up with Apple’s hardware, which ranked far below Wintel solutions in terms of performance, in order to obtain the hardware-locked user experience of their new flagship operating system.
Apple took an unorthodox approach in order to offer Mac OS 9 users the ability to retain their existing software while still upgrading to the improved Mac OS X experience; the virtual machine. Essentially, Mac OS X contained 3 separate application environments; Cocoa, Carbon, and Classic.
Cocoa was the name for the native, Objective-C environment which allowed code to execute directly on Mac OS X without any interpretation or legacy libraries. Carbon was a mid-point solution which allowed older, Mac OS 9 code to be recompiled and then executed in the Mac OS X environment, without providing access to the newer, native UI elements. Classic, the most interesting of the three environments, is the approach that Microsoft will be taking with Windows 7. Essentially, Classic provided a complete API and binary abstraction layer which allows Mac OS 9 code to run within a "virtual machine" inside Mac OS X. Applications retain the appearance and behaviour that they have on the older Mac OS platform, yet still having access to the Mac OS X system resources.
In Windows 7, Microsoft will break from the Windows’ norm by breaking previous API compatibility, offering new API frameworks as a native solution, and providing support for legacy frameworks (COM, ATL, .NET Framework, etc) through monolithic libraries designed to provide the functionality of all previous revisions of the modules in question. This extends/replaces the WinSxS philosophy, providing every single function, past and present, in fully comprehensive libraries. This should allow the majority of legacy applications to run perfectly, while still retaining native performance for applications compiled specifically with the Windows 7 platform in mind. It should also be possible for applications produced with previous versions of Visual Studio to be directly recompiled into native code using the new API frameworks.
This also allows Microsoft to neatly sidestep the DoJ and EU anti-trust rulings, as including the MSHTML library (Internet Explorer’s rendering engine) in the monolithic libraries would provide support for the old rendering functions of Explorer to legacy applications while still remaining hidden from the end-user, the primary complaint in the antitrust cases. On the Windows 7 side of things, Internet Explorer can be abstracted from the Windows 7 codebase making removal/inclusion as simple as installing a normal application.
While the anti-Microsoft naysayers out there will claim that this is unethical business practice, however, technical users will appreciate that this is an excellent way of providing new features while maintaining backwards compatibility with legacy applications.
SimpleDB