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

Does Java have a linker?

[EddWo]

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.

Re:silly objection, and- you can get a linker!

[kzeddy]

this linker shown above does nothing more than merge all the classes used by the application into one big assembly. it does not turn the code into native assembly or link into the assembly and mini hosting environment which is what joel is talking about. YOU STILL NEED .NET

You ask why?

[dtfinch]

Java doesn't have a compile-time linker either. VM based languages tend to only link at runtime.

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

Visual Studio .NET does infact include a linker, for the C++ compiler.

How did this post get moderated up?

[Inoshiro]

All you had was wild speculation ending with, "I've never used .NET,"

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 /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).

But a .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.

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

Before you sit down to learn about .NET, I think you should take off your aluminium beany and learn about how computers work.

Re:silly objection, and- you can get a linker!

[Gyler St. James]

Maybe you should re-read the FAQs yourself.

Microsoft .NET Framework is by any standard a significant installation that one would easily notice; some users may not be willing to install it at all. On the other hand, there are still many PCs that may not be suitable for .NET framework installation. This tool helps you to reach more customers as it silently deploys a trimmed down version of the framework without any noticeable effects and conflicts. The framework appears as an integrated part of your own application.

and...

The mini-deployment tool puts together the minimum set of CLR runtime files and dependent assemblies that can be simply copied to a single folder on a target machine, and your application runs as if the whole framework is installed. Since the installation is isolated into a single folder, there will be no conflicts with future .NET installation. When linking is used for the dependent assemblies, it will further reduce the file size.

In layman's terms, you the developer needs to have the framework installed, but the user does not. It doesn't support Windows 95 because that OS is not supported by the .NET CLR itself. Duh.

Re:We do it because we can.

[Jellybob]

.NET is no longer Windows only - I'm currently in two IRC channels talking with Mono developers, most of whom are on Linux.

Re:silly objection, and- you can get a linker!

[Gyler St. James]

I've been doing .NET development for a long time now (2 years) and for all intents and purposes, the Framework install and the run-time is the same thing. There is no separate download of the Framework classes and the run-time. The framework is merely class libraries bundled into assemblies. Besides, have you even tried the linker mentioned? I have. I've taken the assembly generated and run an EXE on a machine with no updates and no run-time.