Microsoft .NET and Thin-Client Computing

Today, we’re using multiuser OSs to support thin-client environments. Is the next step multiuser applications? In other words, will server-based computing move toward a Web-based environment that eliminates the problems of supporting a multiuser OS?

One possibility for the multiuser application platform is Microsoft .NET, which relies on XML as an application development language. The basic idea of Microsoft. NET is that its applications will be entirely independent of each other—they won't depend on shared DLLs. So with Microsoft .NET, you can avoid "DLL hell," wherein you install an application and overwrite a DLL with the same name that another application was using, breaking previously installed applications in the process. The XML applications will reportedly provide automatic resource management so that memory leaks don’t impact the system. Microsoft .NET isn't just Web-based applications—but distributed applications. The idea is that you should be able to pull information from disparate sources into one format and have the Extensible Style Language (XSL) style sheet provide a template for the data.

Some of the supposed advantages of the Microsoft. NET environment are the same advantages you get from terminal services. One is platform independence, a big issue in a multiplatform world. We have a lot of OSs to choose from, and not every application works on every OS, even among OSs in the same genus. This incompatibility emerges because applications depend on certain infrastructures in the OS—that's what an OS is for—and won’t work unless those infrastructures are present. Another potential advantage is the modular form of the applications on the computer. XML-based applications are supposed to leave the registry untouched and load only the components they’re assigned to use, instead of drawing from a common pool. XML applications should also be easier to install and uninstall. According to Jeff Richter in "Microsoft .NET Framework Delivers the Platform for an Integrated, Service-Oriented Web" (MSDN Magazine, September 2000), ". . . installing most .NET-based applications will require no more than copying the files to a directory, and uninstalling an application will be as easy as deleting those files." Does this process sound familiar to anyone else? I’ve installed an application or two like that—albeit not recently—and I'd love to do it that way again. I’d also like to see applications that are designed to monitor their own resources and thus avoid memory leaks, as .NET applications are supposed to do.

The catch—and you knew there'd be one—is that to run these applications, users need a browser that fully supports XML. And, of course, to get full functionality, the client-side operating environment has to support Next Generation Windows Services (NGWS). According to Microsoft's public statements, if a browser running on a Macintosh or Linux client supports an XML parser, the client can run Microsoft. NET applications—with limited functionality. To my ears, this sounds like, "Microsoft. NET is OS-independent . . . so long as you use a Microsoft OS."

And don’t be fooled: Microsoft. NET is decidedly not a thin-client environment. It looks like server-based computing because you can store applications on a server for browser access, but the processing happens on the client. .NET is not the way to leap off the hardware upgrade cycle.

XML—as part of Microsoft .NET or not—won't replace Windows applications soon. Inertia, if nothing else, will prevent that. People are used to Windows applications. Developers are used to developing for the Windows platform, and, very reasonably, don’t like the idea of starting over. It’s also too early to tell just how well XML applications will stand up to wide-scale deployment.

Finally, before you get too enthusiastic about Microsoft. NET, I have one word for you: Java. The Microsoft. NET idea looks much like the Java idea. Client-side execution? Applications that can run independently of the OS? Sounds familiar. And, with few exceptions (e.g., StarOffice and the HobLink RDP client), Java applications are more theory than reality, in part because some problems keep them from being completely seamless. If Microsoft .NET applications are slow (or perceived as such) and tagged as second-tier substitutes for "real" applications, then they’re not going to make it.

The bottom line is that if you support Windows-based terminal servers with Citrix WinFrame and MetaFrame or with Windows Terminal Services (WTS), you’re not out of a job this year or next. However, XML-based applications look like a good long-term bet. XML has wide industry support (XML's not just a Microsoft initiative), and some really good ideas are tied up in Microsoft. NET. If Microsoft .NET does take off (don’t forget that Microsoft once proposed the idea of the Web-as-desktop, only to drop it), it COULD simplify application development and deployment. And that would be a Good Thing for everyone. If and when XML and a Microsoft .NET application environment become an accepted platform, those who’ve been working with terminal services will have an advantage: They will be more accustomed to the idea of centralized applications than those who’ve been working in a client-centric environment.