A customer recently sent me a long list of questions with a generally skeptical tone. Since I spent a good deal of time generating a written response, I thought it would be useful to share it with readers of this blog.

Note that this is my representation of Microsoft’s history and policies, based on many years as a Microsoft-focused customer, teacher, writer, and now as a Microsoft employee. Any errors are mine alone, and I would appreciate you pointing them out to me.

Dave Schmitt

July, 2006

Questions for Microsoft

Platform Independence and Portability

• Is C# only going to be available on Windows for the foreseeable future?
  
  The C# language and the related .NET runtime known as the Common Language Infrastructure (CLI) have been standardized for more than 4 years by ECMA and more recently by ISO. See the following links:
  
  http://news.com.com/2100-1007-995108.html
  http://www.ecma-international.org/publications/standards/Ecma-334.htm
  http://www.ecma-international.org/publications/standards/Ecma-335.htm
  
  Microsoft has fulfilled its commitment to continue this standardization approach as C# and the CLI have evolved since their initial release nearly five years ago.
  
  In contrast, the Java language has not been standardized and is controlled primarily by Sun. The Java runtime (in the form of J2SE, J2EE, JVM, and so on) is controlled by Sun but heavily influenced by prominent Java platform vendors such as IBM and BEA, as well as by the Open Community Process (OCP).
  
  Because they are standards, C# and CLI are open to anyone who wants to implement them on any platform. Microsoft focuses on the many versions of the Windows platform, ranging from very large server clusters to very small mobile devices. In addition, Microsoft provides a demonstration source code package called Rotor that shows how to implement the C# and CLI standards in a portable way and includes build scripts for BSD Unix and Windows. Novell is working on a commercial version called Mono that runs on Linux and other platforms.
   
• Does .NET solely depend on the Microsoft architecture, and if so what are the risks/limitations of such dependency?
  
  It is definitely true that if you download one of the .NET Framework versions from Microsoft’s web site, you will get an implementation that only runs on specific versions of the Windows OS. It’s also true that the Common Language Runtime (CLR) portion of the .NET Framework includes not only the generic CLI but also many classes that go beyond the CLI standard in order to expose features unique to Windows. In that sense, the CLR depends on the Microsoft architecture, that is, on the Windows OS. However, many aspects of Windows, such as its GUI features, have counterparts in other operating systems, which is why Mono goes beyond the CLI standard and implements source-compatible versions of many CLR features.
  
  It’s also useful to note that popular Java platforms such as WebSphere and BEA include features that are not in “the Java standard” in order to provide more efficient coupling with subsystems unique to the platform. Thus it’s fairly common to encounter large Java systems that are tightly coupled to a specific platform and do not have the “write once, run anywhere” characteristics that are frequently touted as a Java advantage.
  
  Regarding risks and limitations, you need to assess these in your specific context. For instance, consider the issue of hardware risk. Windows runs on any hardware that conforms to the industry-standard PC specifications, which are available at the Windows Hardware Developer Center. Although this is commonly known as a Wintel platform (meaning Windows on Intel), Windows actually has many versions running on a variety of hardware, including RISC processors such as the StrongARM series. Microsoft operates a Windows Hardware Quality Lab (WHQL) that is available to hardware manufacturers who want to ensure that their products conform to the Windows standards. Successful execution of the Hardware Compatibility Test (HCT) in this lab enables the manufacturer to display a logo indicating that the hardware is fully compatible with Windows.
  
  In the past Microsoft shipped versions of Windows NT for processors such as SPARC, although these were discontinued because of the overwhelming popularity of the Wintel hardware. Nonetheless, the internal architecture of Windows still rests on a Hardware Abstraction Layer (HAL) that makes it relatively easy to conjure up a version of the desktop or server OS for non-standard hardware. The Windows source code is available under license, and we also offer products such as Windows XP Embedded and the Server Appliance Toolkit to facilitate some of these scenarios. In addition Windows Mobile Edition (aka Windows CE) is available to OEMs in a kit form together with tools for building custom versions.
  
  When you consider the risks and limitations of doing business with the world’s largest software platform and tool vendor, here are a couple of points to keep in mind.
  
  First, the vast majority of notebook, desktop, and server systems are manufactured according to Windows hardware standards. The ubiquity of Windows-compatible hardware means that IT purchasing agents can negotiate with a broad range of vendors, thereby keeping prices very competitive and avoiding hardware vendor lock-in.
  
  Second, if you choose the Microsoft platform, you are only limited in the sense that you might not be able to run your application on a classic mainframe or midrange machine or on a non-Wintel server or desktop. In most practical situations, enterprises are not interested in moving new applications to their legacy mainframe/midrange systems and would rather migrate the mainframe applications to more cost effective servers. Legacy servers not running Windows remain viable in some scenarios, and they typically use a Unix variant. However, commodity Wintel servers are usually able to offer better TCO. In the desktop/laptop market, Apple hardware is the primary Wintel competitor. Microsoft has been shipping a Virtual PC product for the Mac that enables users to run Windows XP software in that environment. However, now that Apple is moving to a Wintel (or at least Intel) platform, it’s quite possible that Apple will offer even better support for Windows applications. Finally, the mobile device market continues to have several strong OS vendors, including Microsoft, but we are seeing a definite move to the Windows Mobile platform.
  
  The bottom line on risks and limitations is that Windows runs on a broad variety of commodity-priced hardware available from a huge number of vendors. Only Microsoft is able to cover the spectrum from tiny mobile devices to huge server clusters with a cohesive and unified OS and development tool suite that is priced for volume sales and is well supported.
   
• J2EE is being engineered by a group of companies that include hardware and software vendors, it seems that there would be advantages to this. Is Microsoft doing this, and if not, what is the rational for not doing so?
  
  Many, if not most, of the major companies participating in the Java effort are also Microsoft partners in one way or another. You can visit sites such as the Windows Hardware Developer Center mentioned earlier and the Microsoft Developer Network (MSDN) to see the effects of this robust interaction with our partners.
  
  For example, the initial version of .NET was in the hands of developers for nearly two years before its official release in 2002, and it was the beneficiary of a huge amount of feedback during that period. Since then, .NET as well as many other Microsoft products like SQL Server 2005, have been routinely exposed to developers early in the cycle through our Community Technology Previews (CTP) and many other collaborative opportunities.
  
  Microsoft employs a large group of technical evangelists whose primary job is to ensure that users of our technology are well-versed in its capabilities, understand our roadmap, and are encouraged to provide feedback from their particular application efforts. You can see many examples of this work at our case study site.
  
  
• J2EE is an open forum architecture where specifications are reviewed, weighed, and analyzed by the community before they actually become standards. It seems this would be an approach that would identify more security risks and many other factors when developing new standards, is there a reason why Microsoft is not engaging in a more open fashion like J2EE is?
  
  At the risk of being flippant, I’m tempted to ask why, if the Java community is so interested in standards, none of the Java specifications have been put through a formal standardization process with ANSI, ECMA, ISO, or other such bodies. As noted earlier, the foundation of .NET has been standardized by ECMA and ISO. Furthermore, Microsoft (together with IBM and BEA) founded the Web Services Interoperability organization, which has been developing industry standards that are making web services the lingua franca for service oriented architectures. Sun joined this effort long after it started, and the Java specifications continue to lag well behind the actual Microsoft implementation of the interoperability standards.
  
  In addition to our efforts with the standardization committees and industry groups such as WS-I and W3C, Microsoft exposes its architectures to intense scrutiny by vast numbers of users and experts, including many in the Java community. Indeed, one can show that a good number of the J2EE subsystems mimic Windows features released years earlier by Microsoft, and clearly the Java specifications continue to follow Microsoft in areas such as web services.
  
  The major difference between the Java OCP and Microsoft’s approach is that we are motivated to adopt the simplest and most effective solution, whereas the Java community has difficulty reaching that point of closure. As a result, the Java developer often faces a bewildering series of choices in order to cobble together a system appropriate to his or her problem space. That’s why enterprise customers typically adopt a single-vendor approach to their Java needs, choosing WebSphere or WebLogic because IBM or BEA has made the tough choices for them.
  
  Many industry pundits have decried this complexity, which is largely due to the vagaries of the OCP. For instance, a recent report from the Burton Group contains the following summary:
  
  “Java Platform, Enterprise Edition version 5 (JEE5) was intended to simplify the incredibly complex Java Platform, Enterprise Edition (Java EE) but failed to deliver on that promise. The primary value proposition of Java EE—a common programming model for a complete enterprise platform—makes the platform susceptible to disruption by platforms that emphasize ease of development. In this overview, Senior Analyst Richard Monson-Haefel explains how JEE5 fails to save Java EE and why it’s a harbinger of the end of Java EE as the dominant enterprise platform.”
  
  
• .NET supports one operating system and is supported by one vendor.  How difficult is it if (for some reason) we have to implement .NET in Unix or is it even possible?
  
  Windows is many operating systems with a consistent programming model, so in that sense, .NET supports more than one OS. Regarding .NET on Unix or other systems, see the Rotor and Mono comments above.
  
  You might also consider the reverse question. How difficult is it to run a Unix or Java application on a Microsoft OS? Windows has long supported a Unix-compatibility layer that has enabled notable Unix applications such as the original HotMail to rapidly move to more cost-effective Windows servers. The .NET language suite includes J#, a baseline version of the Java language suitable for applications written at the JDK 1.1.4 level. Microsoft is also heavily into virtualization, with its Virtual PC and Virtual Server products as well as the virtualization features baked into the upcoming Longhorn server. Finally, other vendors have been working on the notion of running JVM code on top of the .NET Framework, the most notable effort being IKVM.

• What are the benefits with one vendor support?
  
  Since most enterprise Java customers choose a single platform vendor (typically IBM or BEA), the benefits of one vendor are well known and are not unique to the Microsoft platform. Clearly you want a vendor who will remain viable, has a reasonable technology roadmap, provides high-quality, well-supported products, and conducts business in an honorable manner.
  
  Suffice it to say that a single-vendor approach gives the customer one throat to choke.
  
  
• What are the disadvantages with one vendor support?
  
  Again, this should be obvious. Even if the vendor has what I need today, will they have it tomorrow? Once they get me locked in, will they play pricing games or screw me up in other ways? What is their track record for long-term support of their platform? If they drop support, what will it cost me to move to some other platform? To get a handle on these questions, you need to examine the vendor’s current and past practices, as well as their willingness to share their future roadmap with you.
  
  Microsoft is proud of its support legacy. We have seldom, if ever, discontinued any popular platform technology. Indeed, you can still run ancient MSDOS apps on modern versions of Windows, and COM is still fully supported as the component programming model from the 1990’s. Our large staff of evangelists is constantly briefing customers, user groups, and industry pundits about our future plans, and they also solicit feedback that helps modulate these plans to better meet customer needs and to provide more seamless support for interoperation with or migration from other platforms.

Security

• Microsoft has a poor track record with security, is there any defense to this statement?
  
  Microsoft actually has an excellent record dealing with security issues in a forthcoming manner with an appropriate (and quite large) commitment of resources. For instance, during the first 18 months after Windows Server 2000 was released, Microsoft issued 55 security bulletins. During the same period after the release of Windows Server 2003, the number was 17, due largely to the massive amount of work (reportedly costing upwards of $300 million) to carefully examine every line of code for security problems.
  
  A detailed review of security issues with Microsoft and other platforms is beyond the scope of this document, but we can arrange a briefing from one of our security experts if appropriate.
   
• Along the same lines as above, the community seems to believe that Microsoft is more prone to viruses and worms, why is this and how does Microsoft handle this?
  
  In December 2004, Nathaniel Paul and David Evans of the University of Virginia compared security in Java and .NET.  They found that after 3 years of life, the Java VM had 15 major platform vulnerabilities, as compared to zero such vulnerabilities in the .NET CLR after a similar period.  At the time of publication of their analysis, security analysts had discovered 44 major platform vulnerabilities in the Java VM, while the total for .NET was zero. The authors argue “that .NET’s design is fundamentally more secure than Java’s, and in particular, that it benefits from following general security principles that have been learned and reinforced from experience with Java.”
  
  
• Is it a true statement that Hackers target the Microsoft platforms due to the known track record in security and making Microsoft an easier target?
  
  Hackers target the Microsoft platform for the same reason that burglars target mansions, because that’s where they are liable to find expensive jewelry. The ubiquity of Microsoft technology in mission critical applications provides what military planners call “a target-rich environment.” Hackers are no longer immature young men looking for a moment of glory. Rather, they are criminals seeking financial gain or cyber-terrorists working for a variety of disruptive purposes.
  
  Again, Microsoft has security experts and guidance documentation focused on these issues and our response to them.  

• Some Fortune 500 companies selected J2EE due to its more proven track record on security, has .NET compromised on security?
  
  In October 2004, Gartner Research published the results of an Enterprise Tracker study showing that the use of .NET for mission critical enterprise applications exceeded the use of any other platform.
  
  Forrester’s survey of 822 North American enterprises conducted in May of 2004 found that 56% of them prefer .NET for their primary enterprise platform, versus 44% for J2EE.

Time to Market and Tool Set Productivity

• Learning curve for prior users of Microsoft tools & technologies
• Majority of App Delivery Teams Favor J2EE; and some .NET.
• Does J2EE provide tool sets that are more productive than .NET?
  
  Numerous benchmarks and actual case studies contradict these statements. See Microsoft Marketing Bulletin: Comparing .NET to J2EE and the document .NET Momentum Evidence. These are both in the attached zip file.

Scalability and Performance

• There are claims that .NET has more independence, scalability, and performance issues than J2EE, what steps has Microsoft taken to prove it’s worth in these critical categories?
• Are record transactions and simultaneous user activity as scalable as J2EE?
• Being that the latest .NET framework is newer than J2EE, does it lack maturity?
• Questions persist about the scalability and transaction capability of the Windows Platform, how does Microsoft live up to these areas?
• Does J2EE have better Application Availability & Reliability that .NET?
  
  Many of these questions are addressed in the documents mentioned earlier and in the hundreds of case studies published on the Microsoft web site. If this evidence does not convince you, we can arrange to have our experts drill down deeper as appropriate.

Maintainability and Complexity

• How easy (or difficult) to modify applications under the .NET platform?
  
  Obviously it depends on the overall soundness of the original application architecture. Every architect and developer knows that you can design weak applications on strong platforms, but it’s difficult to build a strong application on a weak platform. The .NET platform has proven to be extremely strong and robust, with a superior tool set, a huge knowledge base, and strong community support.
  
  In our case studies, developers often comment on their increased productivity when they moved to .NET Framework because it has a cohesive OO design that follows industry best practices and standards.  
  
  
• What is the Market Resource Availability for .NET developers compared to J2EE developers?
  
  In March 2006, Tim O'Reilly said on his blog:  "Based on book sales data, it looks like ASP.Net 2.0 is on fire, with ASP-related book sales up 53% since the same period a year ago, versus PHP, down 3%, and JSP, down 25%."
  
  
• Is there a stronger resource pool for C# vs. VB .NET?
  
  Yes in some geographies, no in others. C# is attractive to the “semicolon” crowd, made up of C, C++, and Java developers. VB.NET is attractive to experienced VB developers or those who prefer a more verbose language.
  
  
• Are there any benefits of one .NET language over the other?
  
  The .NET Framework was designed from the beginning to support multiple programming languages, as evidenced in the term Common Language Infrastructure (CLI). The type system and other CLI features enable an implementation of just about any programming language on this platform, and more than two dozen .NET languages have entered production from Microsoft and its partners. These include not only C++, C#, VB, and J# from Microsoft, but also such classics as Fortran, Cobol, and RPG from other vendors.
  
  As Don Box once noted, “Your programming language is merely your viewport to the runtime system.” So, as long as a .NET language gives you an unobstructed view, language choice is simply a matter of syntactic and stylistic preference, not functional differences. The main .NET languages supplied by Microsoft give you an unobstructed view of the CLR, and so are equally viable choices for building robust .NET applications.

Longevity of Product and Company