A .NET primer for Mac users

by Charles Wiltgen

Why did you write this?

I wrote this after reading a confusing rant called Microsoft’s .NET & The Advent Of (More) Nuisance Technology on a site called MacObserver.

The misrepresentation of .NET in that story concerned me — not because it was negative, but because the author confused .NET with Microsoft’s now-on-hold web services (once called Hailstorm, then .NET My Services). A critique of this primer, Why Microsoft’s .NET Is .Not For Me from a site called Low End Mac, makes the same mistake. Slamming .NET because you don't like .NET My Services is as silly as slamming Mac OS X because you don't like .Mac.

With the exception of the great products created by their rebel (or at least that’s what I like to think) Macintosh products division, .NET is likely to be more relevant to Macintosh than anything that Microsoft has done before. Since .NET’s relevance is fairly intuitive once you understand what it is, the goal of this primer is to bring the Mac users up to speed with .NET. (Making this goal a bit more difficult than it should be is Microsoft marketing, which has the unfortunate tendency to huddle even pre-.NET products and technologies under the .NET umbrella.)

This primer discuss only technologies that I consider part of .NET, and then only ones I consider relevant to the Macintosh community.

Who are you to say?

I use Mac OS X and Windows XP daily. I consider myself fairly technical for a product manager, and I've done quite a bit of research into .NET in order to make responsible choices about future versions of my product. I figured that I could help the Macintosh community understand .NET’s relevance as well as anyone.

What is .NET?

Microsoft calls .NET their “XML web services platform". Since that makes sense only if you know what both XML and web services are, here’s a mini-overview.

XML

XML is just a standard way to represent data. If you're not familiar with it, here’s a simple example:

<?xml version="1.0” standalone="yes"?>
<author>
    <first_name>Charles</first_name>
    <last_name>Wiltgen</last_name>
</author>

The first line identifies the file as XML. This XML has an author element which in turn has first and last name elements.

Web services

The best definition of web services that I could find was written by Doug Tidwell of IBM:

Web services are a new breed of web application. They are self-contained, self-describing, modular applications that can be published, located, and invoked across the web.

Web services perform functions, which can be anything from simple requests to complicated business processes. A simple web service might provide stock quotes or process credit card transactions.

Once a web service is deployed, other applications (and other web services) can discover and invoke the deployed service.

You can imagine a web service that returns an author (as in my example above) when it’s sent an ISBN number.

Web services communicate via XML covered in SOAP, a communications protocol for XML messages.

.NET would be good for Macintosh even if it was only good for creating standards-based web services, which can easily be consumed by Mac OS X applications. AppleScript in Mac OS X even has built-in support for web services via SOAP and XML-RPC (the spiritual daddy of SOAP).

Web services can easily be hosted on Mac OS X as well, of course. Although I seem to hear less and less about WebObjects, Apple's web applications platform, UserLand’s Frontier and Radio are examples of web services platforms that run on Mac OS X. All of these web services platforms can easily interoperate with web services created with .NET.

.NET technologies

The .NET platform is a collection of technologies. Here are the ones I find relevant to Macintosh.

CLR

The CLR is the Common Language Runtime, the virtual machine at the heart of .NET. The CLR manages executing code and provides services like memory management, thread management and security.

Many think Sun invented the virtual machine with Java, but the concept has been around for almost as long time as computers themselves. In 1975, Bill Gates and Paul Allen wrote their BASIC interpreter for the Altair 8800 on an Intel 8080 simulator — a virtual machine — based on an Intel 8008 simulator that Paul Allen created for an earlier project. (Paul Allen, of course, did not invent the virtual machine concept either.)

You'll see the term managed code in many articles about .NET. Code running within the scope of the CLR is considered “managed”, and code outside the scope of the CLR — i.e. all Windows software today — is “unmanaged”. (They said it, not me.)

To Mac users tempted to pooh-pooh the whole virtual-machine thing, remember that Apple was able to pull off a virtually-seamless transition from 680x0 to PowerPC only because of the excellence of their 680x0 virtual machine. Additionally, old Mac applications work so well in Mac OS X (and don't take down the whole OS when one of them crashes) because of its Classic virtual machine.

Mac analogy   The CLR is to .NET what the Java Virtual Machine and Mac OS’s 680x0 emulator is to Mac OS — a method for executing bytecode that can’t be executed natively on the host CPU.

MSIL (Microsoft Intermediate Language)

Microsoft’s .NET compilers create MSIL rather than x86 code. The MSIL is in turn compiled to native code by a JIT (just-in-time) compiler and then executed by the CLR.

Since the CLR starts with MSIL code rather than x86 code, .NET makes the host processor — or at least the instruction set of the host processor — irrelevant. In the same way that Virtual PC lets me run Windows applications without putting more money into Intel’s coffers, there’s no reason I shouldn't be able to buy Virtual .NET to run .NET code on my Mac.

You might think that Intel might be worried about this. However, it’s a safe bet that Intel will do fine competing purely on speed and price rather than the momentum of a million mediocre x86 applications, and in fact probably appreciate being unchained from the compromises imposed by their previous x86 architectures. After all, .NET code will run on all of their processor families (including ARM and Itanium).

Mac analogy   MSIL is to .NET what Java bytecode is to Mac OS.

The .NET Framework

The .NET Framework is a class library that gives developers a rich collection of services for developing .NET applications, whether they're conventional Windows applications, ASP.NET (web) applications, and even (shudder) command-line applications. All .NET languages use the same .NET Framework.

Mac analogy   The .NET Framework is to .NET what Cocoa’s Foundation Framework and Application Kit framework are to Cocoa developers.

Visual Studio .NET

Visual Studio .NET is Microsoft’s new development environment.

Mac analogy   Visual Studio .NET is to .NET what Project Builder and Interface Builder are to Cocoa developers.

.NET languages

One of the most brilliant bits of .NET is that developers can use nearly any language to create .NET applications. Not only that, but .NET defines standards that allows multiple languages to work together in the same application.

Microsoft will provide .NET compilers for C#, C++, Visual Basic, and JScript. Other vendors have announced .NET compilers for APL, COBOL, Eiffel, Perl, Python, and Scheme.

C#

Pronounced “C sharp”, the goal of this C-ish language is to bring modern programming concepts to a simple, elegant language rather than forcing software developers to master the disaster that is C++.

Although James Gosling (the inventor of Java) thinks that C# isn't, my opinion is that Sun should've stuck with their original feeling — panic. While Sun has racanted on promises to relinquish control of Java to standards bodies, C# is already an ECMA standard. By 2010, I predict that Java will be an also-ran unless Sun opens Java (which ironically makes .NET a good thing for the Java community too).

Microsoft will be using C# for more and more of their own product development, including future versions of Office.

Mac analogy   C# is to .NET what Objective-C is to Cocoa.

Visual Basic.NET

The name suggests merely a new version of Visual Basic, but VB.NET is really an “inspired by” language. It’s amusing to watch Visual Basic gurus running around like Unfrozen Caveman Lawyers ("Your world frightens and confuses me!"), itemizing how it throws their world in chaos.

Frankly, as a VB newbie I can't imagine anybody putting up with pre-.NET Visual Basic.

Mac analogy   Visual Basic.NET is to .NET what REALbasic is to the Mac platform. AppleScript Studio could be the Visual Basic.NET of the Mac platform, but as it stands, AppleScript Studio

ASP.NET

ASP.NET replaces ASP (Active Server Pages) as Microsoft’s platform for web development. ASP.NET applications can be written in any .NET language, and have The .NET Framework at their disposal.

ASP.NET applications generate standard HTML code, and so will work with your browser of choice.

Mac analogy   ASP.NET is to .NET what PHP is to the rest of us.

.NET My Services

Formerly called “Hailstorm”, .NET My Services is a collection of XML web services that Microsoft hopes will lead them to the promised land of subscription-based revenues.

The article I mentioned at the beginning mostly equated .NET with .NET My Services.

Mac analogy   .NET My Services was going to be to .NET what .Mac is to Macintosh. The future of .NET My Services is uncertain.

What is .NET not?

Win32

Win32 is the pre-.NET Windows API, which can be compared to the pre-Carbonization Mac OS APIs.

.NET code uses the .NET Framework classes instead. The .NET Framework is a comprehensive, modern class library, and seems far more portable than Win32.

Mac OS X already effectively supports at least one virtual machine (the Classic environment). There’s no reason it couldn't support .NET applications as effectively. In fact, I'd be very surprised if future products from Microsoft’s (excellent) applications group weren't written in C# using The .NET Framework.

Mac analogy   Win32 is to .NET what Carbon is to Macintosh — an entrenched API that their makers wish developers would stop using, but that will be around for a long, long time.

COM

COM is the Win32 component (software object) model.

CLR replaces COM (Microsoft’s previous object model), MTS (Microsoft Transaction Server) and COM+ (Component Services). This is a good thing for Mac users since these technologies were not-very-portable Windows-isms.

Mac analogy   COM is to Windows what QuickTime components are to Macintosh.

ActiveX

ActiveX controls are a type of COM component that generally have a built-in user experience. ActiveX controls used to be called OLE controls, and its “cool” rebranding some years ago seems to have been in response to the popularity of Netscape plug-ins and Java applets.

Slides buried deeply within Microsoft’s site promise ActiveX for Mac OS in the first half of 1997, but that statement was obviously a preemptive strike against OpenDoc that Microsoft lost interest in once it became obvious that OpenDoc was stillborn.

In .NET, ActiveX controls are replaced by Windows Forms controls.

Mac analogy   ActiveX is to .NET what OpenDoc would’ve been to Macintosh, had it not been pathetically slow and hard to develop for.

The registry

The Windows registry is a system-wide database. It’s where Win32 code puts preferences and other information it needs to retain while it’s not running, and where shared components (and any components that those components depend on) must be registered before any code that uses them will work.

Sometimes the registry gets corrupted, in which case it’s often “grade 'n' pave” time. (To Microsoft’s credit, I was able to get through a minor registry corruption by upgrading to Windows XP.)

The registry only allows the registration of one of each version of a component, so all applications that use version X of component Y will break if anything happens to that registry entry, or if that version of the component becomes corrupted. (This is commonly referred to as DLL Hell.)

With .NET, shared components are possible but considered evil. Developers will keep private versions of the components they need. Using private copies of components rather than shared components will take up more disk space, but this isn't the problem it was when shared components were all the rage — hard drives are cheap, and system stability is valuable.

These private components become part of an assembly. .NET applications consist of one or more assemblies, and an assembly consists of one or more files along with a manifest that includes lots of information that the CLR needs in order to use the files.

Mac analogy   The registry is to Windows what the Preference folder is to Mac OS.

Non-Microsoft .NET implementations

For my money, the success of non-Microsoft implementations of .NET will be key to the of success of .NET as a platform.

Got Mono?

Mono is an effort to do open-source versions of the most interesting pieces of .NET — the CLR, the C# compiler and a .NET Framework-compatible class library.

If you're a Mac OS X developer and can contribute to the Mac OS X version of Mono, subscribe to one or more of the Mono mailing lists and start kicking ass. (Please?)

DotGNU Portable.NET

This is a free software implementation of pieces of .NET, including a C# compiler, an assembler, a disassembler, and a runtime engine. The initial target platform is Linux, but their intent is to support other platforms in the future.

Corel

Reminiscent of Microsoft’s investment in Apple, Microsoft's $135 million resuscitary investment in Corel had with some significant "to do" items as conditions. One of them was to port pieces of .NET (including .NET Framework, the CLR and ASP.NET) to Linux. Rene Schmidt of Corel has disclosed that they are also porting the .NET infrastructure to FreeBSD for Microsoft. BSD UNIX is also the core of Mac OS X.

Finally

It’s the end of Windows as we know it, and I feel fine.

References
Change history
  • 2002.10.23 — Update to reflect cancellation of .NET MyServices rollout
  • 2002.01.28 — Tweaks based on reader feedback
  • 2002.01.24 — Initial posting