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?"
When you considre the fact that .NET is a windows only platform you would think they'd have one.
Something similar to the JAva linkeR ???
I've used it-- very effective.
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
They don't have a linker because .Net is a virtual machine Jit compiler as well as massive class library.
It will just become part of the Windows platform, its already included with Tablet PC, Media Center, Server 2003, Windows Mobile 2003 and it will be a major part of Longhorn.
No one asks for a linker to statically link to user32 or GDI.
"Taligent is still pure vapor. Maybe they'll be the last who jumps up on Openstep... "
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"
Java doesn't have a compile-time linker either. VM based languages tend to only link at runtime.
.NET runtime caused my Visual Studio .NET to become instable. I'll probably have to get the newest Visual Studio before I can get much use out of it again. It makes everything incredibly slow to load as well.
.NET does infact include a linker, for the C++ compiler.
You improve one library, retaining interface compatibility, and every program that depends on it benefits without having to recompile. Executable code doesn't get duplicated in memory each time a new process sharing the same library starts. Libraries can benefit from globally shared objects without running the risk that a program compiled with an older version will mess stuff up. Etc.
But you're right about this being imperfect. Upgrading my
Visual Studio
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
Having never read him before, I can't be 100% sure of the above title, but I can say that I won't be visiting his ruminitions on society anytime soon. I think he is a loud-mouth moron.
.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... and his part on ranting of all the updates he needed to do - well, just further proof he is not staying on top of taking care of his system. The .NET runtime should not have required him to install anything else besides the runtime. He is clearly clueless when it comes to system administration (or writing untrue things to try to get more people up in arms) if he really wants a linked executable he can drop on a box with no other expectations.
.NET - written by the same guy after all).
I can't see a good reason why he would want a linker to link the
At the end of the day, the question he should have asked would have been something more analgous to the java compiling goodness in gcc to generate native code and not java byte code. That I could seem some benefits to, but really he should just be programming in Delphi or C++ Builder (not all that different from
I stand behind my classification as Joel as an absolute moron. He is nothing more than a bad journalist trying to get people up in arms with his so called facts and loads of ranting.
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.
I guess Joel or his programmers couldn't figure out that you can open the project properties and actually select which run-time you're targeting. It's rather easy and doesn't require you to write your own manifest (although you could). The idea behind the manifest is when you have to dynamically link to other people's DLLs or apps and not the run-time. If the 3rd party happens to upgrade to another version, that's okay. That's why they came up with the idea (or rather re-invented) of side-by-side execution, which allows you to specify with version of the 3rd party DLL you want to use. Joel, get a clue, man! I've been doing .NET development for 2 years now and the first thing that I learned about was the versioning aspects that .NET brings. I will admit that there's nothing new or "brilliant" about .NET, other than it's a vast improvement over Java. But come one guy, do a little reading and research before moaning and grunting at Microsoft. I'll even admit I have no great love for MS either.
I do love the comment from an above poster that points out the .NET linker available. If only he'd gone a little googling, he could have saved us all a few more minutes on our tickers by not writing such an asinine rant, er, article.
Then you won't need libc at all. Linux (really gcc) has that capability, even if you don't want to use it.
[whine] [whine] [whine]
.NET has support for versioning far above any current platform, as it was designed in from the beginning. No, I do not know from practice, but I HAVE read the whitepapers, reviews and interviews. It specifically has provisions for concurrent versions of libraries (even in the same program), and has various compilation and runtime options. This directly obviates the need for static linking in the first place. Java doesn't have a linker either, and has about a 9 MB download last time I checked. I don't know what the hell he is talking about having to download so much stuff. I somehow got .NET automatically and didn't even NOTICE I got it until I opened Add/Remove Programs app, for some unrelated reason. (that is an entirely seperate issue).
Wtf is that rant about? As far as I can tell, the
News flash - new technology requires new, usually larger, downloads. BFD.
OMG I DIDN'T REALIZE I HAD TO PUT GAS IN MY CAR WHAT A RIP OFF!! I'M SO RESENTFUL NOW!!!
It's 10 PM. Do you know if you're un-American?
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."
Whoever wrote that article failed to do step #1: RESEARCH.
.NET, and very little researh yields phrases like "The .NET runtime has side-by-side execution."
.NET-based graphics program, which I'll call "Imagerizer 1.0", which uses the .NET runtime version 1.0 let's say. You also have a .NET-based database program, "Storzit 2.5", which uses the .NET runtime version 1.1.
I code in
What this means is very simple: You have a
You have BOTH of those runtimes installed, if you want to run both of those programs.
Imagerizer 1.0 will ALWAYS use runtime version 1.0, however it will use the newest version of 1.0 (for example 1.0.3.3 vs. 1.0.2.2). Storzit 2.5 will always use the latest version 1.1 runtime.
Simple. No more DLL hell - for a tradeoff of extra clutter. But the runtime will manage it all for you, and you can usually mess around with it more. It's actually much more control given to the end user.
I'd also like to make a few remarks...
Tell whoever is mucking around with manifests to just stop. I let Visual Studio compile my projects with near-default settings, and they load the proper runtime fine. I, too, fear manifests.
As for your bad experience downloding 80MB repeatedly from Windows Update, you could have used a centralized Update Server... being a software company, it'd probably be wise to look into.
As for the premise of your complaint, it does have merit. It would be ideal to be able to link your entire program into an EXE, especially for small apps. However, Microsoft's decision is the right one.
Everybody complains they're insecure - their response was total lockdown.
.NET also makes it rather disgustingly easy to have applications which either dynamically generate and execute code, or can take actual .NET code in whichever language and execute it on-the-fly. Though it's not guaranteed in any case that it'll actually compile and run, it's much more likely when there's a well-known set of libraries out there on "every" machine.
I think Joel's point, which half the flamers on this thread don't seem to get, was that if you're writing software today, and you're trying to get customers to download it tomorrow, writing for .Net is probably not a smart move.
I realise that .Net theoretically has a decent versioning system. However, as someone who's been responsible for investigating new versions of Visual Studio at two different companies now, I've seen plenty of problems in the real world. VS.Net 2002 and VS.Net 2003 really don't play nicely together for a start, and if Microsoft themselves can't get it right with an application whose entire focus is on .Net, what hope does Joe Developer have? I'd be very wary of risking my whole application by trusting a technology so unproven to get the version control right.
And as of today, I think Joel's point about download sizes is also entirely reasonable. I bet the critics here are all happily sitting at home, probably in the US, probably with free local phone calls and always-on broadband. I bet most of them also don't realise that most of the world doesn't have those facilities today, and nor are many of them likely to any time within the next few years. I still have the same 56k dial-up modem I bought when I left uni five years ago, because broadband still has too many practical problems here, and I'm a professional developer and part-time geek who spends several hours on-line some days. I only got a flat-rate package about 3 years ago (before that I was paying per-minute) and even now I'm capped in the number of hours I can use each month, so big downloads are not high on my list of Good Things.
IOWs, as you say, short term Joel's points are very relevant. Later on -- probably 5-7 years away at a minimum -- if 95+% of the Windows user base has .Net installed and/or many more people have broadband, then it might be less so. But 5-7 years is an eternity in software development. For short- to medium-term developments, Joel's comments were right on the money. Using C++ with a good set of libraries is still far ahead of .Net if the size of your executable matters.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Isn't it Microsoft he is complaining about and not the linker? He is complaining about the installation process of .NET. He is complaining that his brain is hurting and wants a stomach surgery.
I think it's only to lock you into the .Net Framework. There is a runtime necessary so that you have to follow their rules before running apps that use their 'neat' little apis. Microsoft claims that they can then 'increase security to all .NET apps' by only having to patch your runtime files, instead of all your apps. While that may be true on a very very limited scale (say patching an exploitable hole in the runtime api itself), it won't be helpful if the user (of the api, not the end user of the app) does something dumb that exposes a hole. All things considered (well as far as I can see) it's really about locking you in. "We can't have people actually building binary code anymore, then they can run it wherever they want!" (Mono is probably a big thorn in their side, on this note)
Speak for yourself.
He doesn't want a linker, he wants something to eliminate the need for a VM, some kind of CIL compiler.
Taral
WARN_(accel)("msg null; should hang here to be win compatible\n");
-- WINE source code
Joel misses an important fact in his article... that the same scheme for versioning in .NET is used for the framework itself. So that when the next version of the framework is installed, your application will use the same old version if needed. In theory, no fuss, no muss.
This guy need to understand that .net complied applications need the .net framework to run because of the nature of the language. You can run a java program without its runtime installed , its the same concept. It will not complile into a single executable which can run on its own like c++ for examample, whcih is complied into native code (binary). .net is extremely similar to java (coincidence, i think not), it is just not ported to linux/mac like java is...yet? The java/.net runtime has its advantages, liek garbage collection and some error checking, but it will always run slower than native code. native code can just be run, while java and .net assemblies are interpreted at runtime. Performace hit for programmer firednly feature. Compling nativ code, ex c, is more powerful, but that comes with responsibilty. An example is memory management, which you are responsible for in c, is controlled be the runtime in these runtime langauges.
A singles exe cannot be run anwhere, only on win32 platforms. A big advantageof java/.net is portablility. One the runtimes are ported to all platforms (*nix, mac, pc) the same complied program will run on all platforms without being recompiled like a c program woudl have to be. The runtime woudl deal with it ewll at runtime.
I am never reading anythign at the joel guys site ever again. he is uninformed and ranting rampant.
Actually, apps for game consoles do contain the entire operating system. So does any app that comes on a bootable Linux CD such as Gentoo, Knoppix, Gnoppix, Mandrake, Lindows, etc.
To make a .NET program stand-alone, you could either include the interpreter and all parts of the class libraries
The class libraries are copyrighted. Would Microsoft give you a license to redistribute the class libraries? And would newer class libraries work on older Microsoft Windows operating systems?
Handles versioning of library interfaces in a reasonably sane way.
Microsoft might intentionally make newer libraries incompatible with older operating systems: "In order to run an app that uses System.Foo.Bar, you must pay us $200 per computer to upgrade your operating system to Microsoft Windows Longhorn DRM Edition." Would you consider such a requirement a "reasonably sane way" to "[h]andle[] versioning of library interfaces"?
10 LET M$ = "Microsoft"
I don't see much problem (maybe I'm missing the point) using newer class libraries as part of a stand-alone, statically linked application on an older Microsoft Windows operating system
M$ Internet Explorer 6 doesn't run on Windows 95, and from the information M$ has published, IE 7 probably won't run on Windows 98, Windows ME, or Windows 2000. Likewise, M$ would likely make newer class libraries deliberately incompatible with older Windows operating systems in order to force users to upgrade.
I got a cool Logitech gizmo for Christmas that I still haven't been able to use, because it requires the .NET runtime which simply won't install on my PC. I just get a generic "Set up failed" message. Microsoft Customer Support doesn't reply. Logitech Support--after six requests for help--finally offered a few things to try, none of which worked.
Relying on Microsoft to install a new technology on older machines puts Logitech at a real disadvantage. They should have built a traditional app until .NET is more stable.
This post explained some questions raised in the overbloated commenting [about side-by-side execution] and should be rated accordingly, not as "0, Flamebait"