Linker missing in .Net ?

I think this is a great rant against the .Net runtime, so I like to post Joel's note as it is, because I share the same feeling. It's true that for Web applications, we have no problem.

But why we can't build ourselves a light embedded version of the runtime in our Windows projects, having only the libraries we need ? Joel give a good 'real world' example. I still have users with Windows 98, and I still have the pain to check that they have the right framework.

From Joel on software:

For some reason, Microsoft's brilliant and cutting-edge .NET development environment left out one crucial tool... a tool that has been common in software development environments since, oh, about 1950, and taken so much for granted that it's incredibly strange that nobody noticed that .NET doesn't really have one.

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. Then, it removes any library functions that your program does not use. Finally, it produces a single executable binary program which people can run on their computers.

Instead, .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.

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. For example right now for some reason our internal company control panel is rounding sales figures to four decimal points, as a result of upgrading from 1.0 to 1.1 of the runtime. Usually the incompatibilities are worse.

In fact .NET includes an extensive technology system called "manifests" which are manifestly complicated and intended to insure that somehow only the right runtime will be used with a given application, but nobody I know can figure out how to use them.

This calls for a story. At the Fog Creek New Year's Eve party, we wanted a bunch of computer screens in the main room to display a countdown until midnight. Michael wrote an application to do this in C# with WinForms in about 60 seconds. It's a great development environment.

My job was getting countdown.exe to run on three computers. Sounds easy.

Nope. Double click the EXE, and I got a ridiculously user-hostile error message about mscoree.dll or something, followed by a gratuitous dump of my path. No mention of the fact that the problem was simply that the .NET runtime was not installed. Luckily I'm a programmer and I figured that must be the problem.

How do you install the runtime? The "easiest" way is through Windows Update. But Windows Update really wanted me to get all the critical updates first before I installed the runtime. That's reasonable, right? Two of the "critical" updates were a Windows service pack and a new version of Internet Explorer, both of which required a reboot.

All told, for each computer I needed to run this little .NET application on, I had to download something like 70 or 80 MB (good thing we have a fast net connection) and reboot three or four times. And this is at a software company! I know how long it took, because the first time it started downloading, I put Office Space on the big screen TV, and by the time the movie was over, the installation process was almost finished. Every ten minutes during the movie I had to jump up, go to each computer, and hit OK to some stupid dialog box.

This is frustrating enough for our in-house apps. But think about our product CityDesk. Almost all of our users download a free trial version before buying the product. The download is around 9 MB and has no additional requirements. Almost none of these users has the .NET runtime yet.

If we asked our trial users, usually small organizations and home users, to go through a movie-length installation hell just to try our app, I think we'd probably lose 95% of them. These are not customers yet, they're prospects, and I can't afford to give up 95% of my prospects just to use a nicer development environment.

"But Joel," people say, "eventually enough people will have the runtime and this problem will go away."

I thought that too, then I realized that every six or twelve months Microsoft ships a new version of the runtime, and the gradually increasing number of people that have it deflates again to zero. And I'll be damned if I'm going to struggle to test my app on three different versions of the runtime just so I can get the benefit of the 1.2% of the installed base that has one of the three.

I just want to link everything I need in a single static EXE that runs without any installation prerequisites. I don't mind if it's a bit bigger. All I would need is the functions that I actually use, the byte code interpreter, and little bit of runtime stuff. I don't need the entire C# compiler which is a part of the runtime. I promise CityDesk doesn't need to compile any C# source code. I don't need all 22 MB. What I need is probably five or six MB, at most.

I know of companies that have the technology to do this, but they can't do it without permission from Microsoft to redistribute bits and pieces of the runtime like the byte code interpreter. 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.

 

6 Comments

  • I hear ya....



    just a few notes on why I think they did what they did:



    Dynamic code -- for example would you compile the same x86 code for a PII on WIn98 and for a P4 running XP ? infact I think that when you install the .net package it pre-jits some of the files based on the system it installs on.



    also with reflection and the ablity to generate code at runtime it may be very hard to find the compile time dependancys....

    yes an advanced program can create a class in memory and jit it.... not many will but...

    there are time when it's slick.



    standard platform, if you hand out the code in bits and chunks then versioning that code is a total mess. and if we keep embeding dependancys to fixed dll's then the "overhead" on a users hard disk could get realy ugly realy fast, imagine if you had say 15-20 apps that all had the same 4 megs in each one...

  • 20 apps, 4 megs duplicated in each one, makes 80 wasted megs. A cheap hard drive these days has 120,000 megs. What's the problem again, denny?

  • I guess I'm a little confused here. He's complaining about needing to regularly check Windows Update in order to use the latest applications? How much hand-holding do people need? I have absolutely no sympathy for anyone who hasn't been keeping up with the critical updates, programmer or no, especially considering the fact that a lot of the people who complain about things like this are the same people who were attacking Microsoft for not making Windows Update mandatory.



    Anyone familiar enough with computers to know which updates they need or don't need will probably know enough to search Microsoft's site for the stand-alone runtime installer. Most users will be able to find their way to the download given the vaguest hint to do so, let alone a direct URL, in the documentation for the program that they're trying to use. If you as a user can't even manage that, well, you are the reason why disabling the automatic Windows Update service should require a license.



    One wonders why it never occurred to him, after almost two hours of waiting for Windows Update to finish, to cancel the update and go directly for the runtime installer.

  • David, you seem to be missing the point. The fact is he should have never had to install anything to run this application. The program should have been compiled into a single exe that includes everything needed. There is no need for an entire framework of which he uses maybe 2%. I wouldn't say this would need to be mandatory, but it should be an option we have.



    Also David, you can't expect every single person that uses a computer to update it regularly. That is just not realistic at all. Developers should not lose out on sales because their target consumer can't figure out how to get the required runtime. And we also cannot fault our Mr. Doe consumer for not knowing. From their perspective getting and using software shouldn't require any effort at all.

  • Thats like bundling the win32 libraries on an as-needed basis. Do we really need to re-bundle core .NET components with each app? After all, the .NET runtime is really the next generation of win32 library. imo, bundling pieces of the .NET runtime with your app is a step backwards, and would cause more grief than joy in the long run.



    In regards to HD space, sure, HD is cheap, but that doesnt mean I want to waste it like that. Thats like arguing that we don't need to code for efficiency since ram and processor speed is cheap.



    I also find it strange that Joel, proponent of hiring the best coders possible, has a staff that cannot understand .NET manifests. Be a programmer, learn to work with manifests, and properly version your software :)

  • I agree with the origional post. i am currently doing a complete data system from a to z for a large shipping company, and I am sooooooooooo tired or writting and re-writting manifest and updating windows, every time I do a new version. I spend at least 50% more time than I need to just making the software work on the client work stations. This time should be spent on actual program code , and not Microsoft wants to change the world coding. My employer is paying me for microsofts ignorance and not my actual programming skills.

Comments have been disabled for this content.