In general, Windows Vista boasts a lot of fancy new features targeted at the home user and, frankly, a lot of “user experience” features aimed to directly compete with the Mac. For the engineers of the world, however, there are some relevant changes, specifically regarding security, the networking stack, new communication capabilities, potential performance gains and faster memory access. At the same time, real-time developers face big challenges with Windows Vista such as determinism, reliability, application control and compatibility issues (especially with I/O).
First, consider the beneficial changes. If you are involved in a lot of networking and communications applications, you probably have experienced some difficulties and will be happy to hear that the Windows Vista networking stack has been completely rewritten. Instead of the dual stack model that exists in Windows XP, Windows Vista implements a new architecture for which there is a single transport and framing layer that supports multiple IP layers. While it’s a good thing that this new stack is more modular, it will cause some compatibility issues, and developers must carefully evaluate these changes to understand their impact on applications. Windows Vista does not support several TCP/IP stack elements, including the firewall-hook driver functions, the filter-hook driver functions and the Internetwork Packet Exchange (IPX) protocol.
Another communication area that brings some exciting changes is the new .NET Framework Version 3.0 (formerly known as WinFX). In the past, engineers created software for Windows by interacting with the operating system through calls to the Win32 application programming interface (API). In Windows Vista, .NET Framework 3.0 is the new interface for interacting with the operating system. This interface was completely redesigned to be easier to use and more consistent across all Windows Vista features. 3.0 is based on Microsoft .NET 2.0 and adds four new technologies: Windows Workflow Foundation (WF), Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF) and Windows CardSpace (WCS). These new complementary technologies were added to address some of the most arduous challenges of contemporary software development. Even though the API was redesigned, if you have existing applications that call into Win32, they should continue to work just as they did before due to Microsoft backward compatibility.
Security is definitely the biggest change and the driving force for Microsoft behind the Windows Vista release. Any improvement in Windows security should be viewed as positive even though to implement a more secure OS may mean a bit more hassle on the part of the end-user. Windows Vista is delivering a more secure desktop through something called User Account Control (UAC). The main goal of UAC is to reduce the exposure and attackable surface area of the operating system by requiring all users to run in standard user mode. This limitation minimizes the ability to make changes that could destabilize the computer or inadvertently expose the network to viruses through undetected malware that has infected your computer. It also, however, limits the access and control you have over the OS and installations. For example, anytime you encounter a system task that requires administrator privileges, such as attempting to install an application, Windows Vista will notify you and require administrator authorization (Figure 1).
The other big feature is 64-bit capabilities. At first glance, any engineer would hope for and assume instant performance gains such as those seen during the move from 16- to 32-bit applications and operation systems. The move to 64-bit, however, is different. To start, 64-bit applications do not magically get faster access to memory or any of the other key components that would help most applications perform better.
Other caveats around the 64-bit issue: you cannot run a 64-bit application on a 32-bit chip or a 32-bit operating system. That means all of your drivers will need 64-bit versions that will be separate binaries from the 32-bit version. A separate binary has a huge cost, from a development point of view, associated with it—but it’s required at the I/O level—so you need to look for that from your vendors.
Apart from driver software, many 32-bit applications will not be updated for Windows Vista x64 Edition; however, most 32-bit software will still function because of a Microsoft emulation layer. This emulation layer, known as Windows on Windows 64 or WoW64, enables 32-bit programs to run as though on a 32-bit version of Windows by translating instructions passing in and out of 32-bit applications into 64-bit instructions. Emulated programs act as though they are running on an x86 computer and operate within the 2 Gbytes of virtual memory that a 32-bit version of Windows allocates to every process. However, despite Wow64, 32-bit programs on Windows Vista x64 Edition cannot take advantage of the larger 64-bit address spaces or wider 64-bit registers on 64-bit processors (Figure 2).
When it comes to porting to and using Windows Vista, the biggest challenges for real-time developers are compatibility (I/O), determinism, reliability, and control of the OS itself.
As mentioned, 64-bit system requirements and 64-bit application security designs are going to cause compatibility issues mostly if your applications involve I/O and hardware device drivers. The above 64-bit discussion pointed out several of the issues that you may experience if you try to upgrade—specifically because your tool vendors will eventually need to create separate binary versions of their application software and drivers. Additionally, application software will at least need patches because many application development tools access the Windows registry in a manner incompatible with Windows Vista rules. Basically, you need to think about and engage in compatibility discussions if you either plan to move to an entirely 64-bit-based version of Windows Vista (need new drivers and application software) or use the Windows Vista networking stack.
The next area for consideration is performance. Moving to Windows Vista will not deliver instant performance gains and, in some cases, may slow your applications down. Similarly, many of the new features such as the Windows Vista GUI also cause slowdowns for your current applications. While detailed benchmarks will eventually be released, it seems like there are some generalizations we can make. It sounds like heavy GUI applications like games will typically run 10 to 15 percent slower on Vista than on Windows XP. For less intense applications, Windows Vista seems to perform roughly as well on the same hardware as does Windows XP. One caveat: don’t expect your 512 Mbyte machine to run Windows Vista effectively, unless your normal workload involves running a single application at a time.
From an overall performance perspective, it’s a little sad that Vista doesn’t take more advantage of multicore processors. On both Windows XP and Windows Vista, multicore processors are certainly more efficient than their single core predecessors. But they both handle multicore processors identically. It will take a future reengineered Windows version to truly take better advantage of the unique capabilities offered by that kind of hardware.
To help monitor many of the Windows Vista performance issues, the operating system comes with a new, built-in benchmark tool called WinSAT. WinSAT runs during the setup procedure to perform a batch of tests to determine whether or not the system is capable of running the new user interface and compositing system. While it doesn’t provide application-based benchmarking information, it does tell you how Windows Vista performs on specific hardware. The tool is really designed for OEM system providers to make sure they meet Microsoft marketing requirements, but can be used by you as a rough guide to performance of Windows Vista on your system as well as a system diagnostic tool.
Advantages to a Real-Time System
Even with new tools and techniques, general-purpose OSs such as Windows Vista are designed to host a diverse set of applications including your e-mail programs, accounting software, desktop publishing, video gaming and engineering tools. A general-purpose OS is expected to respond to all user inputs from the mouse and keyboard instantaneously. As a result, you cannot optimize desktop OSs for deterministic performance. In contrast, real-time operating systems (RTOSs) are designed for highly reliable, deterministic performance. Your RTOS differs from desktop OSs such as Windows Vista in three ways:
•OS scheduling mechanism ensures that high-priority tasks always execute first.
•Software developer has explicit control over all system tasks.
•System does not require user input from peripherals such as a mouse and keyboard.
However, you can (and should expect the ability to) use a Windows Vista system to develop and download code for an RTOS just as you would from Windows XP. In the beginning, some tools may lag in native 64-bit system support, but, in general, the development of a real-time application should not be too different on Windows Vista.
While Windows Vista is clearly not a good RTOS, nor was it intended to be, Microsoft has created guidelines to help you design some applications to be more reliable and manageable (Figure 3). Windows Vista offers a set of new APIs and developer services to make your applications a bit more predictable and manageable as well as some tools to help diagnose them when they are not. These include the following:
•The Event Logging System has been rewritten for added performance and scalability. Using the new event logging for monitoring, troubleshooting and analysis of events, you can make your application (especially for smart clients) easier to deploy by using Windows Installer and ClickOnce.
• Cancelable I/O allows for the asynchronous cancellation of I/O requests and the detection of times when a device is not responding to a cancellation request.
• Restart Manager reduces the need to reboot the PC by giving applications and services the ability to “freeze-dry” their states before being stopped by Windows Vista so that installations can update shared files.
• Application Recovery enables applications to control which actions are taken on their behalf by the system when they fail.
• Task Scheduler 2.0 provides the programmatic creation and scheduling of tasks.
So, do you need to rush out and get Windows Vista on your development machine? It definitely has a cool factor that’s intriguing to many developers, and the security capabilities are worth the investment. If you have an upcoming break in projects, it may be a convenient time to upgrade your PC and OS. A good litmus test to gauge the port involves answering the following questions:
• Are you only developing real-time applications on Windows and then deploying them?
• Do your projects and applications require minimal or no hardware support?
• Does your hardware vendor have 64-bit drivers available?
• Do your tools vendors offer Windows Vista compatibility?
• Is security a top concern for your organization or current projects?
• Are speed and performance not top concerns for your application?
If you answered “yes” to more than two of these questions, it may be worth your time to schedule the port to Windows Vista. However, if you have a lot of I/O and need minimal jitter, it is clearly not a replacement for your RTOS or a good place to host your real-time systems. In the end, Windows Vista should be a more productive and secure environment for developing many of your real-time applications. Happy Windowing!