Introduction

As a software developer of many, many years , I ve written programs for numerous platforms and operating systems, all of which had their advantages and disadvantages. Generally, most platforms and operating systems were similar to their predecessors with incremental improvements.

To date, Microsoft Windows itself has evolved this way. Initially, writing a Windows application meant programming to the Microsoft Win32 API. ^[1] Microsoft designed the Win32 API as a flat, procedural API callable by C programs. At one time, Charles Petzold s book Programming Windows , which introduced this API, was required reading for any Windows application developer.

The nice thing about the Win32 API is that it lets you do pretty much anything you want. ^[2] You get first crack at all Windows messages and can respond to the events that they signal in any appropriate (or inappropriate) way. You can modify memory ”your own process s memory or even another process s memory ”however you want, security permitting. You can draw a window any way you like. You job is simply to get the correct bits to the screen in the correct places at the proper times.

The design of Windows itself is actually quite object-oriented. You manipulate window objects , use graphical pens , and so forth. However, you perform these operations by calling the correct APIs (out of the thousands available) in the proper order and passing the proper data types, mostly without compiler help when you get it wrong.

When Microsoft first released Windows and for a number of years after, software developers typically wrote monolithic, isolated applications. Developers had no components from which to compose applications and no mechanism that supported composition, and applications did not attempt to communicate with other applications on the same system, let alone with an application on a different computer.

In 1993, Microsoft introduced the Component Object Model (COM). Microsoft designed COM as an attempt to solve the following two problems. COM introduced a binary standard so that components, produced by different source language compilers, could interoperate using immutable interface definitions. The Distributed COM (DCOM) network protocol allowed these components to interact across process and machine boundaries.

Many of the Windows APIs that Microsoft introduced after 1993 are COM- based APIs. Two examples are the DirectX and Shell extensions APIs. Today, Windows has over 10,000 APIs designed by many different developers on many different teams with different goals. As a result, Windows exposes some of the APIs as flat, C-language entry points in a dynamic-link library (DLL). It exposes other APIs as a set of complex, interacting COM interfaces. There are other APIs that you access using other technologies.

In practice, you, the developer, want an operating system to shield you from most of this complexity most of the time. Therefore, many different teams, within Microsoft and without, developed various framework libraries to simplify application development. Some popular framework libraries are the Microsoft Foundation Classes (MFC), the Microsoft ActiveX Template Library (ATL), Microsoft Visual Basic s library, Borland s Object Windows Library (OWL), and no doubt many others.

MFC, for example, attempts to wrap the various idiosyncrasies of the Win32 API with a consistent and object-oriented set of C++ classes. When your programming language of choice is C++ and the MFC libraries directly support what you want to do, your job is easy. However, when you want something slightly outside the mainstream, you are mostly on your own again and, in fact, in worse shape than before because now you have to figure out how to use the Win32 APIs, plus make your work interoperate with the existing MFC classes.

ATL lets you write extremely efficient COM objects, and to a lesser extent Windows applications, using obscure and, to many developers, poorly understood C++ template-based classes. It s not a far stretch to say that you could easily end up with highly efficient objects that no one could understand.

Microsoft s Visual Basic team took a different approach. They wrapped access to the Win32 API in an easy to learn and use language and library, but at the expense of removing functionality and options. Visual Basic makes it extremely simple to produce components for applications and the applications that use such components. However, Visual Basic doesn t allow you complete access to everything the Win32 API offers. Sometimes the Visual Basic developer simply cannot accomplish a task because of restrictions imposed by the chosen development environment.

In the early to mid-1990s, the World Wide Web took off. Computers started to become more and more connected. Initially, a Web browser simply rendered static HTML, and browsing the Web was a lot like looking at a magazine page.

When Microsoft released Internet Explorer 4 in 1997, other possibilities arose. Developers could create HTML files containing script plus markup. Objects in the HTML object model gained behaviors, and you could write script that responded to events and provided customized behavior. HTML pages could now react to user events on the client and respond far more quickly than prior Web-based applications that required a roundtrip to the server for each screen update.

One big advantage of Web applications was that you could easily deploy the application by simply copying over a set of files to a server. The next time a client browsed to the application, she interacted with the latest version.

Another big advantage of Web applications was the built-in support for rich media integration. Flow-based page layout and support for multiple fonts, graphics, and multimedia content is far easier to provide via a Web application than it currently is via a Win32 application, regardless of the framework you use.

Overall, however, it s still difficult to write Web applications today because programming language and library support for such applications is limited. Debugging Web applications is often a nightmare. In many ways, the client user experience still isn t as rich as that provided by client applications based on the Win32 API because of the limited set of controls available to Web applications.

By the late 1990s, a Windows developer often had to specialize. You were a Win32 API programmer and could write any kind of client application slowly. Alternatively, you were a Visual Basic developer and could write relatively rich, form-based user interface (UI) applications quickly but couldn t write certain other types of applications at all. An MFC developer somewhat straddled these two extremes, although in practice, you needed to be a proficient C++ developer who was familiar with the Win32 API to be a good MFC developer. ATL and COM-object developers were often the plumbers of a system and provided components for these other developers to reuse.

In 2000, Microsoft introduced .NET. The definition of what exactly .NET is differs depending on whom you ask. In my opinion, .NET is a modern software development platform for producing, more rapidly than one could previously, correct and secure Windows applications that use the latest technologies, such as XML, and Web services, while still allowing access to your heritage code.

.NET in general, and managed code in particular, provides a number of benefits to the software developer:

• An object-oriented, language- agnostic , type-safe object model.

• Reduced conflicts between different versions of components.

• Reduced number of bugs and security holes due to common programming mistakes. For example, there are no more buffer overruns and no more memory management errors.

• A single framework and set of libraries that all developers can use. The .NET Framework class libraries encapsulate the most commonly used Win32 APIs plus numerous additional APIs provided by many SDKs in a unified package.

• Higher abstractions than were previously available.

In some ways, .NET is simply a new object-oriented, language-agnostic framework that encapsulates many aspects of the Win32 APIs. Personally, I prefer to think of .NET as a state-of-the-art replacement for the Win32 APIs ” incomplete as yet, but becoming more complete over time.

For example, .NET version 1.0 provides object-oriented, form-based client application development classes. You could think of these as simply wrappers over the basic Win32 windowing APIs. However, .NET also provides ASP.NET classes that encapsulate Web application development and HTML plus behavior generation. These classes in effect extend the Windows API and aren t really a wrapper for anything in the Win32 APIs. .NET s rich support for Web services and XML in general are two more examples of new functionality provided with .NET rather than simple wrappers around existing Win32 functionality.

What This Book Is About

This book focuses on the Microsoft Longhorn features for the developer. From a developer s point of view, Longhorn provides new functionality we can broadly categorize in five areas:

Longhorn Application Model

Longhorn defines applications in new, more powerful ways.

• Longhorn APIs are managed classes that handle much of the programming housekeeping and reduce the workload of the developer. All third-party developer compilers and tools that support the .NET Common Language Runtime (CLR) automatically support the new Longhorn APIs.

• The Longhorn application model supports both traditional form- based and new page-based navigation applications. Application page-based navigation support is provided by the operating system.

• A new Longhorn security and privacy model, which is the result of a combination of managed APIs and digital identity, provides application security from the beginning of the development process. Longhorn applications and components are trusted because of their use of managed code.

• The Longhorn APIs represent the best development concepts from a variety of contemporary technologies. In many ways, the developer is no longer constrained by design decisions made more than a decade ago.

• Automatic application state management and retention for easier application development.

• ClickOnce deployment technology supports sophisticated deployment features such as installation in Program Files, versioning, Side- By-Side installation, and Drizzle Download.

• Inductive UIs lead users through a task.

• Accessibility and automation features are built into the platform. Your applications automatically gain such support.

Trustworthy Computing and Security

Longhorn bases an application s security on the common language runtime code access security (CAS) model but with significant extensions.

• Longhorn recognizes that some applications are fully trusted and others have only partial trust. Applications that fully participate in the Longhorn security model will have full access to Longhorn s features. Applications that only partially participate in the model will have some benefits, albeit with restrictions.

• Longhorn provides an ultrasecure, managed-code, runtime environment, called the Secure Execution Environment (SEE), that protects the user from bad application behavior.

• The Trust Manager provides a scoring system for Longhorn applications that determines a suggested level of trust that users could grant to the application.

• Longhorn provides a security Trust Center that allows a user to manage hot fixes and access Windows updates. In addition, a Security Advisor informs the user of security risks and violations.

• Digital Rights Management is a part of managed code, giving strong protection for intellectual property. This allows secure storage and transmission of previously vulnerable intellectual property in the Longhorn environment.

• Longhorn uniquely identifies users and computers using digital signatures. When combined with a signing authority for verification, Longhorn can securely and reliably identify individual users in computing scenarios.

Rich Storage and Data Access

Longhorn provides significantly improved application data storage and access via a new file system.

• Windows Future Storage (WinFS) is the new Windows file system based on structured query language (SQL) technology.

• The new ADO.NET provides improved data access.

• Common schemas for everyday information, such as contacts, organizations, addresses, and much more, allow shared information access by applications, the operating system, and the shell. In fact, the new shell user interface is one of the heaviest users of the new storage system.

• An application can attach additional metadata to objects in the file system, which allows faster search and retrieval of file objects than is possible with a traditional file system.

• Changes in objects in the Longhorn environment are automatically propagated to other instances of those objects using dynamic data binding.

• WinFS allows easier propagation of data across clients and servers using data synchronization and replication, removing complexity for the developer.

Communication and Collaboration

Longhorn applications now have a rich variety of communication and collaboration features.

• Features such as sessions and channels provide rich collaboration services to participants .

• Communication and collaboration features can securely operate through firewalls and Network Address Translation (NAT), allowing traversal of corporate boundaries.

• Standardized communication based on Web services allows legacy and new applications to participate in collaboration.

• Server-based/peer-based communications features can operate over centralized infrastructure or directly to user clients.

• Virtual presence support allows users to collaborate with others through instant messaging “like features (common notification, invite, and so on).

• Integrated security is an integral part of these capabilities.

• Shell Extensibility support, such as collaborative verbs (use of a default chat client, and so on), can be identified to make use of familiar tools in Longhorn s real-time communication.

• Common controls such as the new People Picker control provide high-level application support for communication applications.

Rich Presentation and Media

Developers can more easily produce applications providing rich user interfaces using the presentation and media services available in Longhorn.

• Longhorn provides the developer with rich graphics classes that provide animation, effects, and visually exciting images that exploit hardware acceleration.

• Powerful declarative and dynamic vector graphics allow flexible presentation and scaling for high-resolution output devices while saving resources because graphics are generated from a descriptive language.

• Easily applied animations improve usability and continuity of the UI.

• Graphics support uses hardware accelerated DirectX/3D video cards to create a more immersive and fluid environment.

• Your application can seamlessly integrate all forms of user interface ” images, video, audio, vector graphics, controls, text, and so on.

• A new layout model allows for rich text and media display because of a framework that automatically adjusts pagination, position, and so on to the screen size .

• New text services such as the inclusion of subpixel rendering (ClearType) allow for a visually engaging GUI on any PC with a 3D accelerator independent of possible screen resolutions .

• You can merge disparate pieces of data into containers, which can be moved around the UI.

• Conditional transformations of data based on type, value, or other rules gives the developer tools to create a more facile UI.

• An extensive multimedia platform allows a glitch-free playback of audio and video; distributed A/V experiences between PCs and consumer electronics devices; highest quality audio and video codecs; high performance for real-time, high-definition content capture and editing; rich CD, DVD, and television metadata services.

^[1] Actually, it was the Win16 API at one time, but they re conceptually the same.

^[2] The less nice thing is that you pretty much must do everything you want.