Asp calendar script

Windows is moving beyond the desktop and farther into the Internet. Microsoft Corp.'s .NET initiative enables developers to build applications that exchange data with a variety of Internet-based providers, which Microsoft calls Web Services. As you would expect, Microsoft is also developing new server applications—and updating old ones—to work in this .NET environment.

Such a significant shift in computing technology used to take years (as from the DOS interface to the Windows interface), but the Internet has greatly accelerated the rate of adoption for new technologies. Still, the move to a full .NET world will take some time, perhaps several years.

End users will likely see the least impact from .NET, at least initially: The user interface in Microsoft's .NET vision is rendered either as HTML or using a new, Windows-based forms package. Ultimately, end users will get more feature-rich applications, but really .NET is all about what happens behind the scenes: how data is pulled from off-site suppliers, how certain operations are handed off to specialized providers, and how data is moved around independent of targeted devices.

Methods for developing software and administering systems will likewise evolve. In fact, the nature of .NET systems may cause valuable computing resources to be reallocated: Rather than spending the bulk of development resources on custom in-house solutions, businesses may develop services that can be offered to other organizations.

Although .NET initially targets the Windows/Intel platform, Microsoft has designed the underlying architecture—known as the .NET Framework—to be portable to other hardware platforms.

.NET Framework

Microsoft announced the .NET Framework at its annual Professional Developers Conference (PDC) in July. Attendees got an early version of the .NET Framework Software Developer Kit (SDK) along with a very early release of Visual Studio .NET, the next version of Microsoft's developer tools suite. By the end of the year, Microsoft will widely distribute beta 1 of both the SDK and Visual Studio .NET. Developers can use these tools to create components and applications for .NET.

This initial release of the .NET Framework features a language-independent Common Language Runtime (CLR) as well as a rich library of extensible software classes. Just as all Windows applications use the core Windows libraries to perform actions like drawing on the screen, printing, and persisting data to a file system, all .NET applications use Microsoft's Base Class Library (BCL) to perform equivalent operations (traditional Windows API functionality is well abstracted by the BCL), as well as new functionality such as data exchange using XML and the Simple Object Access Protocol (SOAP). Finally, the framework includes a new version of Active Server Pages (ASP), which now hosts any .NET-compatible language rather than requiring script-based programming.

The .NET Framework SDK includes additional tools and documentation as well as command line versions of the three .NET-compatible languages in Visual Studio .NET, the next major release of Visual Studio. These languages—Visual Basic .NET, Visual C++ .NET, and a new language, C# (pronounced "c sharp")—all produce code that is compiled into native code and executed by the CLR's execution engine. The .NET Framework SDK is included with Visual Studio .NET and is also available separately for those developers who develop with non-Microsoft language tools.

The core of .NET—the CLR—attracted much attention, particularly within the developer community, and drew the inevitable comparisons with the Java Runtime. Some developers working with traditional tools that offer native code compilation, such as Visual C++, have been openly pessimistic about the performance they expect from a runtime-based system.

Modern runtime systems perform many tasks: program management (object, memory, and code), security and privacy safeguards, and administration aids top the list. They have traditionally fallen short with licensing, though: It is often impossible for runtime component creators to establish and enforce a model that guarantees them licensing or royalties based on use. One of the reasons VBX (and later ActiveX) controls did so well was that Microsoft had created a well-defined licensing strategy, making it fairly easy for a control developer to distinguish between programmer (design-time) and customer (runtime) use—and difficult for unlicensed developers to use the controls. Components created for .NET continue to support the same licensing model.

The CLR differs from other runtimes significantly in its language-independence: Microsoft has documented a Common Language Specification (CLS) for the .NET runtime compatibility. Not only will three of Microsoft's own languages generate .NET-compatible code, but so will those of a number of other vendors. The one notable exception is that there is no announced Java compiler for .NET, but this is due to legal reasons, not technical ones. It is likely only a matter of time before Java, too, runs under .NET.

A common misconception about runtime-based execution is that, as with Java and early versions of Visual Basic, executed code must be interpreted at runtime. The CLR, in fact, executes native x 86 code. This code can be either compiled at runtime, for instance when running from a dynamically generated Web page, or precompiled for better start-up performance. The CLR also handles some programming tasks that have traditionally been left to the programmer, notably memory and object management.

The best programmers could conceivably write code that outperforms equivalent code in the CLR, but for the majority of programmers, relying on the runtime for memory management will likely improve performance and will certainly reduce the number of memory access violations. Obviously, this rich class library and flexible compilation model would be important if Microsoft were to port .NET to non-Wintel platforms.

If the execution speed of .NET code is, as expected, on a par with existing, natively compiled code, a next logical performance concern would be start-up and initialization time. Clearly, initializing the runtime from a cold state (that is, with nothing cached) will have a perceivable impact: In the beta 1 release, expect this to be in the neighborhood of 3 to 4 seconds, with subsequent invocations being substantially quicker. Predicting the performance of the supplied class library, however, is more complicated. Classes that offer a thin layer encapsulating underlying technology—such as the Windows API itself—shouldn't display noticeably poorer performance, whereas classes that make extensive use of new functionality—for instance, XML-based data management—may need significant tuning before the Framework is released.

Class libraries are extremely important, providing developers with a common rich—and usually modifiable and extensible—set of software objects that help make programming more productive, consistent, and accurate. The .NET class libraries encapsulate underlying Windows API functions such as window display, drawing, and process management. The class libraries also provide support for data management (including legacy support for ADO—Active Data Objects—and SQL), drawing and graphics, messaging, Windows Sockets, security, and Web Services. There is strong support for almost anything related to XML, including extensive conversion, transformation, and serialization capabilities. Programmers can also call the Win32 API directly, as well as interoperate with existing COM+ servers—but at that point some of the code management functionality of the CLR is lost.

As this class library is ultimately the replacement of the Win32 API, it is critical that Microsoft get this right from the start. This is something we're likely to live with for many years. With the broad distribution of beta 1, Microsoft will be looking for corrective feedback on missing and hard-to-use features; after beta 1, changes in the class library will be much more difficult to effect.

Data Delivery

It may be convenient to think of data being delivered in three ways: Windows Forms, Web Forms, and Web Services. The first two involve the user interface, where the choice is between presenting HTML and presenting a rich, Windows-based client.