Why .Net will benefit other platforms
Published: 01 Oct 2002 15:50 BST
2. Better support for Microsoft apps on non-Microsoft platforms. Love them or hate them, but Microsoft applications are some of the most popular pieces of software in existence. Microsoft plans to convert most of their products to .Net. Once that happens, they have at least a fighting chance of working on a non-Microsoft platform. Granted, an application could still call into native code which only exists on Windows, or use Windows specific .Net assemblies. However, that's a market opportunity for some company to provide the non-standard feature which prevents Office from working completely.
The ability to support Microsoft applications would go a long way towards establishing the credibility of Windows alternatives among average consumers and businesses, EVEN IF they don't have all the features found in the Windows version. As many have noted in defense of StarOffice, the average consumer needs only a fraction of the features found in the Microsoft Office suite. For most users, even a less-functional Microsoft Office on Linux would be more than enough for their needs.
3. .Net widens the market for those who don't target Windows. ISVs who target non-Microsoft platforms can choose to avoid features specific to Windows, yet still sell their products to the Windows market. This widens the revenue base for these companies considerably, making them more viable business entities and generating revenue that can enrich the non-Microsoft world. Likewise, startups oriented around Linux platforms (as an example) will have an easier time making a business case, as they can include the large market for Windows software in their business plans.
4. .Net binaries are closer to the open source ideal. For a bit of a shock, track down ILDASM.exe in the .Net SDK, fire it up and drop your favorite .Net assembly on top of it. ILDASM stands for "Intermediate Language DisASseMbler," and what it does is use "reflection" to create a visual representation of the contents of a .Net assembly.
.Net, like Java, is completely self-describing, which is essential to a managed runtime's ability to monitor what running code is doing. This means that a surprising amount of information is contained in a .Net assembly, information which makes it very easy to figure out the original source code. Method names, return types, parameter names and types, the names and types of member variables, and other bits of useful information are all included inside of a .Net executable.
Click here for some sample ILDASM output.
ILDASM outputs "IL assembler", which though much easier to understand than regular assembly language, is still not the same as the original source code. However, because .Net assemblies provide so much information about themselves, real, honest-to-god disassemblers generate much better output. A good example is the Salamander .Net Decompiler, which allows you to choose whether you want your code in C#, VB.NET or Managed C++ (which demonstrates one of the advantages of early emphasis on multi-language support).
Of course, obfuscators do exist, an example of which is available from the same company that made the Salamander .Net Decompiler (like selling guns and flower arrangements from the same corner shop). However, Java "suffers" from the same ability to decompile the source code, and thus Java software companies theoretically have the same motivation to obfuscate. Even so, I have yet to run across anything that I couldn't decompile. I suspect the same will apply to .Net. Obfuscators will exist for those who REALLY want to hide their source code, but those who do so will be far in the minority.
5. Boosts efficiency, as developers can program to just one API. There's a reason why programmers tend to fall into warring technology camps. Computing technology evolves very quickly, and it is expensive in terms of time and money to keep up with it. Hence, most programmers choose a particular programming domain, and are reluctant to deviate from it.
This is an unnecessary waste which balkanizes the programming world into isolated, even antagonistic, blocks. A better solution is to find a way for everyone to hook into the same API. This is the approach taken with .Net.
API unification should matter to proponents of non-Microsoft platforms, because the root cause of Microsoft's desktop popularity has been the expense of developing for warring APIs. Favoring Windows is the rational end product of market realities, both for developers who must decide where to concentrate their R&D efforts and for consumers who have to make compatibility calculations. If everyone can use the same basic APIs, then the costs which keep developers and consumers tied to a particular platform are diminished. This increases the likelihood of platform mobility, which boosts the fortunes of non-Microsoft platforms.
Why is Microsoft doing this?
If .Net so undermines the lock-in potential of the WIN32 API, why is Microsoft pushing .Net? First, I don't think they have much choice. A managed architecture like Java is an undeniable improvement over any native API. As the years pass and the requirements (and risks) of a networked environment are better understood, the advantages of a VM style environment like Java becomes more compelling. Hence, Microsoft needs to incorporate this sort of technology if they are going to keep Windows software development competitive in the coming years.
Second, I think Microsoft is more willing to let a bit of Windows market share slip away, so long as the loss is made up through increased sales of application software. Writing for multiple platforms can be expensive. In a networked environment, however, it's very hard to guarantee that everyone will run Windows. .Net makes up for this deficiency by creating a level middle layer that papers over many of the ideosyncracies of a particular operating system. If Microsoft writes to a standard middle layer like .Net, they can sell to everyone with access to a .Net runtime, whether or not they run a Windows operating system.
Additionally, Microsoft doesn't enjoy the attentions of the US government. Giving a bit of ground in the desktop market will take some of the antitrust heat off, and won't be a revenue problem so long as Microsoft can continue to sell to a large unified software market (as currently exists for Windows) and opens new .NET-oriented software markets through which it can leverage its cross-domain industry knowledge (explained further down).
Third, Microsoft is well positioned to remain an applications juggernaut. They regularly make software that ends up taking over its market segment (and no, it can't be explained away by Microsoft's popularity as a desktop operating systems). Microsoft has an organization that enables it to consistently do this, one that gives it a competitive advantage. Furthermore, given the difficulty of changing corporate culture, they are confident that it will be difficult for others to replicate it. As noted in a previous article, Microsoft consistently gets high marks from its own employees. Competitors won't match that overnight.
In addition, Microsoft has a presence in practically every technology market which would benefit from software. That gives them in-house knowledge about the interconnection needs of these markets that no one without the breadth of a Microsoft could hope to acquire. This is a competitive advantage in a world of ubiquitous networks, given that most of these domains either communicate today or can be expected to communicate in the near future.
Conclusion
The biggest barrier I see to the benefits I've enumerated is the resistance of many of those outside the Windows development community to associate with ideas traceable in any way to Microsoft. This is a mistake, because Microsoft has a lot of good ideas, many of them centered around ways of satisfying consumers, both non-technical "normal" users and programmers/corporations. Microsoft is smart enough to absorb good ideas when potential customers have proven they like them (Java certainly falls into this category due to its popularity in the enterprise). It is equally smart for others to borrow ideas from Microsoft.
Instead of complaining about Microsoft's market reach, co-opt it. Embrace Microsoft's protocols and conventions (something made easier by the recent settlement), as Ximian appears to be doing with their "Evolution" Outlook replacement. Accept that consumers like Microsoft's way of doing things, and do it better. That's certainly what Microsoft did in its battle with Netscape. They copied all of Netscape's non-standard HTML extensions (that is, those parts not blessed by the W3C), and endeavored to ensure that IE did everything AT LEAST as well as the dominant Netscape browser. Once they reached parity, they made a functionality leap with IE 4.0 that made IE BETTER, technology wise, than Netscape, thus starting the wholesale shift towards IE.
"It is a pointless battle to pretend that boycotting the use of those (.Net) technologies will have any kind of effect on their reach" (Miguel de Icaza). A friend of mine once described the Judo martial art as "the ability to use your opponent's attack momentum against them." Microsoft is spending billions migrating its developer community to .Net. Leverage that investment, and use Microsoft's own "momentum" to widen your market and boost your platform of choice.
This is Part three of three commentaries on the future of .Net. Read Part one, "Clarifying the .Net Message" and Part two, "Why .Net will conquer the world".
John Carroll is a software engineer who lives in Switzerland. He specializes in the design and development of distributed systems using Java and .Net. He is also the founder of Turtleneck Software.
Previous
Did you find this article useful?
26 out of 45 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
