Why Doesn't .NET Include a Linker?

CrypticSpawn asks: "I read an article on Joel on Software it talks about Microsoft missing one important thing from the .NET infrastructure, and I wanted to know what Slashdot readers thought were Microsoft's reasons for leaving [a linker] out?"

Comments

One possibilty

[sbennett]

One possible advantage to always dynamically linking: when some nasty bug in the runtime is found, it should be easier to upgrade the runtime than to relink every application that's been linked statically to it. Of course, people won't actually bother to upgrade, but you can see how the theory goes.

Yes, I say when a nasty bug is found, and not just because it's a Microsoft product. No matter how good the software is, there's always at least one critical security flaw.

Re:Joel is a schmuck

[Jerf]

I can't see a good reason why he would want a linker to link the .net environment and runtime into a single executable. That is just plain nuts. Yeah, I would rather have my users download a 30MB file instead of a 20MB runtime and a couple hundred K app...

Actually, he had two good reasons, one of which you winged and one that zoomed right past you, likely because you've never had to support software that you wrote and may have multiple versions in the field.

First, he objects that users may not download the larger file (and I'd add that some users will balk at installing what is effectively an OS upgrade just to try some software out, especially corporate users), and that as a result those users won't give him money. Unlike free software, a lost user is cash out of pocket. This is not trivial when software is your living.

This isn't quite what you said because you missed the "money" aspect of the objection, which is critical.

Of course it's easy to mock Joel, because it's his living, not yours.

Secondly, he objects that without static linking, he's at the whimsy of both the users and Microsoft as to which .Net runtime his software actually gets dynamically linked to, and observes that there is a "solution" to this virtually nobody can use (so it's not really a "solution"). Again, if his software doesn't run, it's money out of pocket. And again, if you've never had to support software you probably wouldn't understand why it's nice to bundle everything up, as much as possible, into one self-contained bundle.

I won't go so far as to qualify you as an absolute moron, but you are committing one of the key Moron Sins, which is "Assuming everybody in the world has needs identical to yours and projecting from there." So you're at least partially there with your Rant-From-Inexperience.

Nuisance

[GCP]

where is the surprise in this?

It's not that it's a surprise. It's just a huge annoyance.

Microsoft talks about how much easier it is to create Windows apps with .Net than with the old VC++/MFC approach, and that's so completely true that after you see what you can do with C#/.Net, you can't bear the thought of going back to C++/MFC.

But the fatal flaw for Spolsky and others in his position (including me on occasion) is the delivery of such apps to the enormous installed base if you can't deliver via CD-ROM. Then you're in the same position as people who would rather work in Java or Python or Lisp: your elegant little app has this huge boat anchor of a runtime to drag along with it, and people in the general installed base who get your app via download simply won't put up with it.

VC++/MFC have a huge boat anchor of a runtime, but it's Win32 itself, so it's invisible. The majority of the installed base out there can be counted on to have a huge library built into Win98 (likewise for Linux), and all you need to statically link is whatever wasn't already included in Win98.

For a C(++) developer on Win32 or Linux, this doesn't usually add much baggage, so I almost always statically link and save my users from dependency hell.

But for developers in anything else, the runtime is a major impediment to commercial viability (for certain scenarios).

At first I wondered why MS didn't just AOL the world with .Net installer CDs in everybody's mailboxes. I gradually came to the conclusion that it's because they were essentially gamma testing it first on those more savvy users who could figure out how to obtain it and install it themselves, especially on the server side.

It appears as though they plan to give themselves some time to work out the bugs and flaws in .Net and gradually insert it into the new OSes, allowing the upgrade cycle to control the speed of adoption. The least likely to upgrade will be the least sophisticated users that way, and therefore the people least likely to be able to handle the inevitable bugs in .Net will be the last to get it.

It will take a few years, but .Net is a powerful replacement for the Windows API that will eventually be built in to all Windows machines (and others, if MS gets their way), and then you'll be able to safely deliver a C# app without the runtime.

Of course it's an open question whether developers like me will be willing to wait. The major attraction of Windows for me is the huge market that the installed base represents. The OS itself is of little interest. But it's hard to take advantage of that installed base opportunity using .Net apps at the moment, and I can't see starting anything new with MFC (Yuck! I'd be stuck doing MFC maintenance for years to come). The best way to take advantage of .Net right now is on your own machine -- some sort of server-based app. Well, if it's a server scenario, then what the installed base is running is irrelevant, and I'd prefer to use something like Python or Java or even Lisp on Linux. (We'll see how C# on Linux turns out with Mono later this year with the release of 1.0.)

If there were a way to take a 300KB C# app and turn it into a 1.3MB windows *.exe that would run on a plain vanilla Win98 machine, that would change the economics for me as it would for Spolsky. Otherwise, well...we'll see....