The Old Joel on Software Forum: Part 3 (of 5) - Only three reasons why MS didn't include LINKER..

Only three reasons why MS didn't include LINKER..

I can think of only three reasons Microsoft wouldn't include Linker functionality (to produce a static EXE for distribution) in .net:

1. It's really really hard to do.
(Since there are at least three linkers out there, either they suck or it's not that hard to do)

2. They WANT everyone to be spreading the .net framework around, creating a beachhead for microsoft.
(I don't think this is it either, they could just make the .net framwork a mandatory Windows update if they really wanted it on people's machines.)

3. They really want to cripple the ISV market. They want VB (or .net ) programmers limited to in-house apps. .Net is great for an in-house app. It's lousy for creating a shrink wrap app.

IF everyone got on the .net bandwagon we might find in 3 or 4 years that a new .net comes out ever 6 months so very few of our customers have the latest .net.

We'd be relegated to something other than shrink wrap.

-"A guy who's still making good money on his old vb 3.0 programs"

The real Entrepreneur
Wednesday, January 28, 2004

1. It's not that difficult to create a linker.
2. A linker is included in .NET.
3. Why would Microsoft want to cripple all of the ISV's that support its main product - Windows?

Wednesday, January 28, 2004

Linker in .net?

Where?

Tell me more. I'd LOVE to use .net, but need a simple, easy, lightweight install.

The real Entrepreneur
Wednesday, January 28, 2004

Just one question: What the heck do you think the first L in dll means anyway? ;)

Dynamic linking is still a form of linking.

Sum Dum Gai
Wednesday, January 28, 2004

One more reason: Do you really want to link with MSBlaster worm or something similar? Issue next hour update if remote chance of exploit is found in runtime?

WildTiger
Wednesday, January 28, 2004

.Net is a very clever strategy aimed at commoditising corporate developers while entrenching the platform, which of course is sold by Microsoft Corporation.

Consider that .Net more or less exposes the source code of applications developed by others, certainly to a much greater degree than compiled native executables. This helps spread the platform, while undermining developers.

Secondly, Microsoft is setting itself up as a gatekeeper and policeman for corporate PC's. When most applications run on .Net, Microsoft will be able to eliminate the virus and spam threat by preventing "unauthorised" ie. native, apps from running.

A bit sad really.

Me and the view out the window
Thursday, January 29, 2004

"the heck do you think the first L in dll means anyway? ;)"

Dynamically Loaded Library. :-}

Hermaphrodite
Thursday, January 29, 2004

> Consider that .Net more or less exposes the source code of
> applications developed by others, certainly to a much
> greater degree than compiled native executables. This helps
> spread the platform, while undermining developers.

Could you elaborate on this a bit for those of us who don't know .NET yet? How does .NET expose application source code?
--Michael

Michael Eisenberg
Thursday, January 29, 2004

It's fairly easy to decompile IL (the .NET "bytecode") back into readable source. All you lose are the local variable names. This has actually turned out to be a real blessing for me. If the docs are hazy about something, I just fire up Reflector, decompile the assembly I'm dealing with, and voila! Questions answered.

There are obfuscators that claim to solve this problem, but never having used one I can't say anything about their effectiveness one way or the other.

Java has the exact same problem.

To be honest, though, the only way to prevent reverse engineering this way, regardless of the source language, is to not give people the binaries. This is another reason why the web service stuff is so interesting to a lot of companies. Host the proprietary stuff on your own server, expose a public interface, and you don't need to risk exposing yourself.

Chris Tavares
Thursday, January 29, 2004

The provider of an app that depends on .NET loses the responsibility (and control) for the entire configuration and therefore cannot support its customers.

I've spent more than a month trying to get my Logitech Christmas gift installed. The software depends on the .NET framework, but the .NET installation simply fails without explanation. Logitech Support has no suggestions other than to contact MS. MS Support doesn't return calls. And it's too late to return the gift.

If they had built a traditional app, they could provide workarounds for all sorts of MS DLL screw-ups. With .NET, everyone loses.

Adrian McCarthy
Wednesday, February 4, 2004