.NET UPDATE, January 9, 2003

.NET UPDATE—brought to you by the Windows & .NET Magazine Network


Recover Active Directory on .NET in Ten Minutes!

Microsoft Mobility Tour

SPONSOR: Recover Active Directory on .NET in ten minutes!

As the worldwide Active Directory administrator, I recently got a call at 2 a.m. from one of our remote Active Directory administrators. He had accidentally deleted an entire OU out of Active Directory. Rather than run into the office and search for back up tapes, I rolled out of bed, terminal servered in and fired up ERDisk for Active Directory from Aelita Software. I restored the OU in ten minutes. Problem solved. I went back to bed. Download your FREE eval of ERDisk for Active Directory today and sleep easier.

January 9, 2003—In this issue:


  • Will Forcing Microsoft to Carry Java Create an Even Playing Field?


  • Microsoft: Human Error Caused .NET Outage


  • .NET Framework Basics: The Common Language Runtime


  • Give Us Your Feedback and You Could Win a Digital Camera


  • Integrate Barcode Technology into .NET Framework Applications
  • Use .NET-Enabled E-Commerce Software


  • See this section for a list of ways to contact us.

(contributed by Paul Thurrott, news editor, [email protected])

  • Will Forcing Microsoft to Carry Java Create an Even Playing Field?

  • US District Judge J. Frederick Motz recently granted Sun Microsystems a preliminary injunction in its antitrust lawsuit against Microsoft, requiring the software giant to bundle Sun's Java programming language in Windows OSs. The ruling was unprecedented in the technology industry, although the judge pointed to legal precedent in other industries in his 42-page ruling.

    As Microsoft Chairman and Chief Software Architect Bill Gates once complained about a similar proposal involving Netscape, bundling Java with Windows is like "asking Coke to include a can of Pepsi in every six pack." However, Judge Motz is interested only in leveling the playing field and undoing the damage Microsoft wrought when it illegally attacked Java. Will this ruling level the playing field?

    To understand this complex case, you need to look back to Microsoft's December 1995 announcement that it would license Java from Sun, which the companies finally accomplished in March 1996. Microsoft said at the time that it would include Java in Windows, Internet Explorer (IE), and other products, and would develop its own Java implementation, including a Java programming environment called Visual J++.

    However, as was later demonstrated in Microsoft's epic antitrust battle with the US government and 19 states, Microsoft never intended to be a good Java licensee. Instead, the company plotted internally to "wrest control of Java away from Sun," according to court documents, by creating an incompatible Java version that worked only on Windows and wasn't a cross-platform program. This strategy was in conflict with Sun's "write once, run many" mantra for the Java environment. Microsoft's scheme was simple, as court documents prove: By dividing the market for Java between Windows and non-Windows implementations, Microsoft could stall Java's growth while it prepared a competing technology that, in 1996 and 1997, wasn't even on the drawing boards. That technology, of course, became known as .NET.

    Microsoft performed other illegal acts to hamper Java's success. Because Sun's main distribution mechanism was bundling Java with the then-successful Netscape Navigator Web browser, Microsoft struck anticompetitive deals with ISPs that forced the ISPs to provide IE, rather than Navigator, to their customers in return for free Microsoft server and desktop software.

    In March 1998, Sun sued Microsoft and charged the company with unfair competition, claiming that Microsoft infringed on Sun's intellectual property and violated Sun's trademark for Java. Like the wider antitrust trial, the resulting Java trial proved damaging to Microsoft's credibility, and the companies eventually settled the case, with Microsoft paying Sun $20 million.

    At this point, the situation gets murky. Microsoft agreed as part of its settlement to stop making changes to Java and was forced to ship only an outdated Java version in its products. And by this time, of course, its .NET initiative—originally known as Next Generation Windows Services (NGWS)—was in full swing. Microsoft had a Java killer waiting in the wings: the .NET Common Language Runtime (CLR) environment, XML-based Web services, and C#, a Java-like language.

    For Sun, the legal victory was bittersweet because the damage had already been done. Although millions of developers supported Java, the program would see only a smattering of success on Windows, the dominant desktop and server platform. Without a viable Windows offering, Sun could see Java eventually become a niche player like Borland Software's Delphi development environment or the Novell NetWare server product.

    The Turning Point
    The turning point in this battle was when Microsoft lost its federal antitrust case. During that trial, Judge Thomas Penfield Jackson established a set of legal facts, later upheld on appeal, proving that Microsoft illegally hindered the distribution of Java. Any party could use these facts in independent lawsuits against Microsoft, and Sun responded with a $1 billion suit against the software giant in 2001. As part of this suit, Sun asked the courts to require Microsoft to bundle Sun's Java technology with Windows and IE, in the way Microsoft was starting to bundle .NET. According to Sun's argument, because Microsoft acted illegally to limit Java's distribution, the company should be forced to make Java available by using the same distribution method Microsoft uses for .NET.

    Judge Motz apparently agreed with this argument. In his ruling, the judge wrote that Sun's remedy proposal "is sound ... and appropriate." And on December 23, 2002, he ruled that Microsoft would bundle Sun's Java with Windows within 90 days of the ruling. Microsoft, of course, is appealing the ruling, and the two companies will eventually meet in court to determine whether the injunction will be permanent.

    Motz wrote in the ruling, "Confronted with an innovative product \[Java\] for which it had no substitute (even on the drawing board) and which threatened its monopoly in the \[OS\] market, Microsoft devised and implemented a strategy to deprive Sun of the benefits of Sun's ingenuity and to deprive the consuming public of the full benefits of Sun's invention. Microsoft embraced Java for the purpose of destroying it. At the least, Microsoft bought itself time (seven years, as it turned out) to develop its own competitive product, and it is now bringing that product \[.NET\] to a market its own antitrust violations have substantially distorted. This conduct ... fully justifies denying Microsoft a competitive advantage obtained by its antitrust violations."

    Although you can't argue against the merits of the .NET Framework—the technology is excellent, according to programmers—Judge Motz's characterization of Microsoft's behavior regarding Java is accurate and supported by the legal record. I believe that forcing Microsoft to bundle Java alongside .NET is fair. If .NET is truly the superior technology—as I believe it is—then Microsoft has nothing to fear. If, however, .NET is nothing more than Microsoft's shallow attempt to usurp Java from Sun, perhaps .NET deserves an ignoble fate. I'm interested in what you think: Is this ruling fair? Does Microsoft deserve to be punished? Drop me a note and let me know.


    Brought to you by Windows & .NET Magazine, this outstanding seven-city event will help support your growing mobile workforce! Industry guru Paul Thurrott discusses the coolest mobility hardware solutions around, demonstrates how to increase the productivity of your "road warriors" with the unique features of Windows XP and Office XP, and much more. There is no charge for these live events, but space is limited so register today!

    (contributed by Paul Thurrott, [email protected])


  • Refuting reports that a .NET Messenger Service outage earlier this week was caused by a lack of hardware redundancy, Microsoft admitted yesterday that human error was responsible for the 5-hour service disruption. "We're looking at internal processes to make sure nothing like this ever happens again," said Larry Grothaus, a Microsoft product manager. "It was a serious thing. We apologize."

    Apparently, Microsoft technicians incorrectly configured new routers during a routine upgrade of the .NET Messenger Service; the error dropped an estimated 30 million to 75 million users from the service Monday morning. The company hasn't released any figures, but most people who use MSN Messenger and Windows Messenger, the Instant Messaging (IM) applications that rely on the service, were affected.

    This week's outage wasn't the service's worst, however. In mid-2001, MSN Messenger was offline for more than a week. As more and more customers—especially corporate users—rely on the service, stability and reliability are key to its continued success. "A large degree of reliability is necessary," Grothaus admitted. "We're taking steps to see to it that we don't have outages like this again."

    (contributed by Christa Anderson, [email protected])

  • .NET Framework Basics: The Common Language Runtime

  • During the past year, I've written in .NET UPDATE about details of some .NET Framework pieces—particularly Web services and the newest Universal Description, Discovery, and Integration (UDDI) specification. With the start of the new year, however, I'd like to step back and examine the greater picture of what the .NET Framework is all about.

    As with other system architectures, you can represent .NET with a simple diagram showing how all the parts fall in relationship to one another. The lower a piece is on the diagram, the more fundamental that piece is to the functioning of all other pieces. In the .NET diagram, the foundation piece is the Common Language Runtime (CLR). The CLR is the piece that makes everything else in a .NET application work.

    The CLR is fundamental to .NET's operation because .NET is supposed to be language-agnostic to at least some degree. But making a programming architecture language-agnostic is not a simple task. First, different languages have different ways of representing similar kinds of data—that is, they have different systems for representing types of data. For example, some languages see integers as a series of bits, whereas other languages see integers as objects, and yet other languages see integers as either bits or objects. Even applications or components written in the same language can encounter type system problems if the types aren't clearly defined in the language or an application is using user-defined types.

    Second, type descriptions are usually stored in a separate source file, such as the header files that C++ uses. When a program is compiled, its metadata containing the type information might be lost, meaning that only languages that can read the source file can read the type information. (Type libraries, which COMuses, seek to resolve this problem.)

    These two problems—different ways of defining types and difficulty in making type information available to different languages—can make creating components and applications that are truly language-independent—but that can still work together—difficult. As a simple example, consider how you can use a batch file to run a VBScript script, even though the batch file and the script don't report errors in the same way and don't refer to devices such as logical drives in the same way. And, batch files and scripts are very simple—and Microsoft-specific—ways of programming. The problems increase in scale with the complexity of the language.

    The CLR consists of three main components of the .NET architecture that attempt to resolve these two problems. A type system supports the many types and operations of modern programming languages. A metadata system preserves metadata with types when programs are compiled. At runtime, other compilers can access this metadata. And the CLR's execution system runs the programs, referring to the metadata.

    The catch to the CLR, of course, is that the languages developers use to build .NET applications have to work with it. A type not found in the CLR type system won't work. You might have heard that you can use multiple languages to develop applications on the .NET Framework, but that the application will work better if you use Microsoft languages. It's not that .NET works better with Microsoft languages per se, but that languages that use types found in the CLR will be able to use more of their capabilities. That's why you can use Visual Basic .NET to develop .NET applications, but you can't use Visual Basic (VB).

    And there's the rub. Programming languages are designed to fulfill a particular need, so although programming languages might accomplish the same kinds of tasks, the specific way they conduct those tasks—and the specific tasks they're designed to perform—differ. That's why some languages are better than others for certain operations. A language-agnostic system permits more cross-platform and cross-language development but homogenizes all the functionality.

    (brought to you by Windows & .NET Magazine and its partners)

  • Give Us Your Feedback and You Could Win a Digital Camera

  • Take our very brief, confidential survey on wireless technologies and you could win a digital camera. Click here!

    (contributed by Carolyn Mader, [email protected])


  • IDAutomation.com released Linear.NET Barcode Forms Control, software that lets you integrate barcode technology directly into .NET Framework applications so that you don't need to export data to a proprietary label program to print barcodes. Linear.NET Barcode Forms Control is compatible with any development environment that can use .NET forms controls. A user license costs $199, and a developer license costs $790. Contact IDautomation.com at 813-261-5064.


  • LaGarde announced StoreFront 6.0, e-business software for companies that want to use the Internet as an additional channel to drive sales. StoreFront 6.0 is built on the .NET platform, so developers can launch fast, reliable, and stable e-commerce sites. For pricing, contact LaGarde at 800-943-5823 or [email protected]

    Here's how to reach us with your comments and questions:

    (please mention the newsletter name in the subject line)

    This biweekly email newsletter is brought to you by Windows & .NET Magazine, the leading publication for Windows professionals who want to learn more and perform better. Subscribe today.

    Receive the latest information about the Windows and .NET topics of your choice. Subscribe to our other FREE email newsletters.

    Hide comments


    • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

    Plain text

    • No HTML tags allowed.
    • Web page addresses and e-mail addresses turn into links automatically.
    • Lines and paragraphs break automatically.