Introduction

  • Article

 

Introduction

Brent Rector
Wise Owl Consulting

October 2003

Contents

What This Book Is About
    "Longhorn" Application Model
    Trustworthy Computing and Security
    Rich Storage and Data Access
    Communication and Collaboration
    Rich Presentation and Media
What You'll Find in This Book

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. (Actually, it was the Win16 API at one time, but they're conceptually the same.) 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. (The less nice thing is that you pretty much must do everything you want.) 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. Your 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; plus, 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 Microsoft 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, inside Microsoft and out, developed various framework libraries to simplify application development. Some popular framework libraries are the Microsoft Foundation Classes (MFC), the Microsoft ActiveX Template Library (ATL), the library in Microsoft Visual Basic®, 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" 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.

  • 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.

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" 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.

What You'll Find in This Book

Each of these topics can easily fill a book on its own. Therefore, I'm not going to describe all the various APIs in "Longhorn." I'm also not going to dive into a detailed description of each technology. This is not an API or reference book. I'm sure it won't be long until you can find many slightly edited and regurgitated copies of the documentation available in bookstores.

What I am going to do is show you how to get started developing for "Longhorn." At a minimum, you really should read Chapters 1 and 2 because they cover the absolute basics you need to know to develop applications for the "Longhorn" platform.

In Chapter 1, I discuss the new application model. Do not pass Go. Do not collect $200. You really need to read Chapter 1 or you'll get a Go To Jail card in the mail. I also introduce you to a new markup/programming language in Chapter 1. Whether you're a VB.NET developer, a C# developer, or one of the mythical COBOL.NET developers, you'll need to learn this new markup/programming language. Read Chapter 1: The "Longhorn" Application Model. I'm not kidding. In fact, go do it now and come back. I'll wait.

Okay, now that you've read Chapter 1 and are excited to build your own applications, you probably should read Chapter 2. In it, I show you how to compile, deploy, and run a "Longhorn" application. So Chapter 2 is also important, but there's no need to rush off to it. It's a very patient chapter and will wait for you to finish this introduction.

The remaining chapters introduce the various technologies I've alluded to in this introduction. Chapter 3 is a fantastic introduction to creating user interfaces using the new markup language and gives you a flavor of its power. Chapter 4 introduces the new file system APIs and will likely cause you to abandon the Win32 file system APIs.

In Chapter 5, I show you how to use data binding to move data from practically any .NET object to your user interface and back again without writing any procedural code. I show you how to create powerful, secure, reliable communication applications in Chapter 6. And finally, the last chapter discusses some guidelines for creating modern, connected mobile applications.

Thanks for hanging out until the end of this long introduction. Now it's time for you to read Chapter 2. (You did go read Chapter 1 earlier, didn't you?) Have fun with "Longhorn." I certainly have!

Continue to Chapter 1: The "Longhorn" Application Model

Brent Rector

Brent Rector is president and founder of Wise Owl Consulting (www.wiseowl.com), and has over three decades of experience in software development. Brent has designed and implemented operating systems as well as new computer programming languages and their compilers. Brent started developing Windows applications using Windows 1x beta in 1985 and has been involved in Windows development ever since. He is the author and coauthor of numerous Windows programming books, including ATL Internals and Win32 Programming. Brent is also the author of Demeanor for .NET—the premier code obfuscator for .NET applications.

© 2003 Microsoft Corporation. All rights reserved.

IntelliSense, Microsoft, MSDN, MS-DOS, Visual Basic .NET, and Visual Studio .NET are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners.