Slashdot Mirror
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?"
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.
where is the surprise in this?
.NET if you want. like similar tools for perl and python, it packages everything up that you need into one exe. this took 10 seconds to find via google. Perhaps Joel should try google next time. What is this, ask slashdot? :)
.NET does this and any other system. Sure, there isn't a way to link it all into one .exe file, but that may come in the future. that is, in perl and python (among others) that was the case at first- you had to download a big runtime and possibly other libraries to get your app working. these days, you can distribute your app in that way- a 20KB download of your .pl files,or a big-ass executable that integrates all the requisite libraries, VM/runtime system, etc etc. however, this often ends up giving you a file that it almost as big, but at least, it is a little simpler on the user.
.class file or jar, there isn't some way to encapsulate it all into one double-clickable executable file that I can share. I have to have my users download a big package, the other libraries, and then my app. .NET is no different, and there is no reason to expect it to be. joel gripes, saying that microsoft will come out with a new version every few months. just like with new versions of perl, python or java, there is no reason that the user would neccesarily have to have the brand-spankinest newest version. if your app requires it, you make it a requirement. put it on the CD, and say- install this if you don't have it yet. big deal. if you were smart, you'd write your apps against the most common verison- .NET 1.0 or 1.1 for now, just like a lot of Java apps are still written for Java 1.1, not even Java 2! Most folks don't write apps for the newest Java, 1.4.x unless they really need it.
.NET does it?
first of all, you can get a linker for
there is nothing different about the way
again, Java does this too. If i have a
what the hell is so different about how
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
All you had was wild speculation ending with, "I've never used .NET,"
/usr/lib). The run-time linker resolves all the dependancies and loads the related libraries for every dynamic application you start (run the ldd command on a binary you have to see the libraries).
.NET program (or a Java program, or a batch file, or a shell script, etc, etc) isn't a binary. It's PCode. It requires an interpreter to parse its Pcode. To make the .NET program stand-alone, ala a statically linked binary, you'd need to include the interpreter, a set of all used class libraries, and any other parts of the environment that are required. A typical 1-3mb application would have to be distributed as a 30mb+ file.
.NET programs, you need a .NET environment. It's not some crazy lock-in scheme, miyako, it's merely a fact of how virtual machines and Pcode work.
.NET, I think you should take off your aluminium beany and learn about how computers work.
Let's pause a second and see how programs work on a modern operating system.
There are 2 kinds of programs, typically, in an environment such as your PC: statically linked programs, and dynamically linked programs. Statically linked programs have the library calls included in the binary, wherease dynamically linked programs rely on library implementations stored in a system directory (like \windows\system or
But a
When you want to run a Python program, you install a Pynthon interpreter. When you want to run a Java program, you have to install the Java runtime environment. When you want to run
Before you sit down to learn about
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
For some reason, Microsoft's brilliant and cutting-edge .NET
.NET is neither "brilliant" nor "cutting-edge"--it's a modest evolution from Java, which is itself 1970's technology.
.NET has this idea of a "runtime" ... a big 22 MB steaming heap of code that is linked dynamically and which everybody has to have on their computers before they can use .NET applications.
.NET and Java is to run inside a runtime, a runtime that provides garbage collection, dynamic typing, and just-in-time compilation.
.NET and Java do have serious design problems. Foremost, safe runtimes like that should run all applications on a machine in a single address space. Then, you can get rid of a lot of useless machinery for inter-process communication, and the overhead gets amortized over dozens of programs. Again, old stuff. But Spolsky's criticism is just missing the point completely.
Actually,
The tool in question? A linker. Here's what a linker does. It combines the compiled version of your program with the compiled versions of all the library functions that your program uses. [...] Instead,
Well, that's roughly like saying that automobiles leave out the horses and the whip. The whole point of
Runtimes are a problem, much like DLLs, because you can get into trouble when application version 1 was designed to work with runtime version 1, and then runtime version 2 comes out, and suddenly application version 1 doesn't work right for some unpredictable reason.
Well, duh. So, I guess operating systems are a problem, too.
We solve that sort of thing by having standards and sticking to them. Oh, I forget, besides being rather confused about software in general, Spolsky also actually seems to like Microsoft Windows, so the notion of "standards" and "compatibility" must be rather foreign to him.
where is the surprise in this?
.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.
.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.
.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.
.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.
.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.)
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
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
It appears as though they plan to give themselves some time to work out the bugs and flaws in
It will take a few years, but
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
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....
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."