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?"
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
So Microsoft, wake up, get us some nice 1950s-era linker technology, and let me make a single EXE that runs on any computer with Win 98 or later and no other external dependencies. Otherwise .NET is fatally flawed for consumer, downloaded software. .NET applications you will have to upgrade to Service Pack X", and potentially as a way to force upgrades, "Oh, you have to upgrade to Longhorn to run newer .NET applications" .NET, and a friend had almost convinced me to install a small Windows partition so I could learn C#, but this seems like a big enough pain in the arse to not even bother when there are other alternatives.
Could it be that Microsoft is using this as a way to force people into updating/upgrading their OS? Something like "Oh, I'm sorry, to run newer
I'm not sure, it might not be this at all, but it seems like a really bad thing for microsoft if that is their plan.
The only other thing I could think of is that perhaps they are trying to use this as being similar to the Java Virtual Machine in some basterdised way?
I've never used
Famous Last Words: "hmm...wikipedia says it's edible"
The only three potential advantages to a real linker are:
.net executables working (uh... .Net itself :-)) (a). I understand this in the short term, but over the long term I think it's going to be less of an issue.
a) You dont have to include code you dont use
b) You can ship "all-in-one" executables that work in any environment (excluding the basic OS interfaces)
c) global optimization
If you have an environment that:
a) Shares library usage between processes, and only pages in parts of the library that are being used.
b) Handles versioning of library interfaces in a reasonably sane way.
c) Uses meta-code which can be globally optimized. (.net may not be doing this yet)
You don't really need a linker. Joel's main complaint appears to be about cross version compatibility (b) and all the cruft you need to install to get
Joel doesn't want a "linker", he wants C/C++ or Delphi or some other language that can create self-contained executables. So the .NET runtime is 25MB. Those are the breaks. His employee wrote this little app in 60 seconds, right? Well you can either do that and download 25MB of runtime or spend 25 hours writing it and not download anything.
And of course this posted here looks like yet another evil plot by "M$" to (a) lock in customers (b) stifle competition; or (c) kill baby seals. Jeez.
Considering Joel's track record I'm surprised he framed this "problem" this way. Linker indeed.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
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.
The point is that you can't deliver an app .NET is only useful for enterprises in which
in a reasonble (i.e. minimized) download,
to run on most of the Windows systems out
there: Windows 95, 95 OSR2.5, 98, 98SE, ME,
NT 4.0 sp6a, and 2000 Pro SP4.
all the systems are "upgraded" (more like
"migrated") to XP. That's a rare environment.
It probably only happens in small businesses
or colleges.
-I like my women like I like my tea: green-
This is very true. .NET wasn't even available until recently. In other words..
.NET framework, then .NET is not right for you. Can't really be mad at Microsoft for requiring a 24+MB framework download that was not even available until the WinXP days.
If your target audience is using Win98, and they don't want to download the
If your software company is distrubuting CD's, you can always put the framework on CD and install it with the app. It is a redistributable component per the EULA.
Well, ok, I see why you might find this annoying, but look at it from another perspective:
;)
First of all, because you're compiling to CLI and using a runtime, you don't have to recompile your code every time a vulnerability comes out and you decide your users should patch. They patch the runtime and the app keeps working (knock on wood). A related benefit is that as the runtime improves, your users get a performance boost without you having to lift a finger, if, that is, they're keeping up with their patches (I know, I KNOW).
Look at a related technology to see this in action: Between Java's JRE 1.3 and JRE 1.4, Sun added a feature that compiles classes to native code and caches them. This is basically an improvement to a runtime that ends up benefitting all code that uses the runtime, without recompiles or rollouts. Users just upgrade their JRE, and poof. Performance boost.
Ok, another benefit of a runtime is, you don't have to worry about installed libraries, DLL Hell, or any other similar thing. You just make sure your users have the most recent copy of the runtime, and you're set. No more having to figure out dependencies and make sure they get into your MSI. No more having to run RegCrawler on user machines to strip out a dozen instances of the same DLL because some brainiac sysadmin kept re-registering the same dll over and over again (YES, I've had to clean up this kind of thing before, when updating legacy code that hadn't been installed with an MSI -- Ugh). Everything is clean and easy, and everything is where you would expect it to be. Nice for a change, after years of VB6 and dll hell.
Finally, since the runtime is really only a 25MB download or so, as pointed out by another poster, you can put the install on a mini-cd along with your code MSI and write a script that installs one, then the other -- can't you? It seems to me that that would be relatively trivial. And, everyone who makes a runtime grants developers some form of redistribution rights, don't they? It seems to come with the SDK most of the time.
I think you're underestimating the value of this approach. Plus, you're overestimating the difficulty of working with it.
Come on, Strangelove... LOVE the bomb.
Farewell! It's been a fine buncha years!