The Old Joel on Software Forum: Part 3 (of 5)

Speaking of Linkers

Since Joel was so nice to raise this issue with respect to .NET, I feel the urge to add in another RANT.

I have always felt one of the biggest problems with VB is the missing linker. Requiring the distribution of the VB runtimes is a big pain in the a??. Although the VB runtimes aren't as big as the .NET runtimes I think the issue is still the same. Now if MS had give both VB and .NET the issue to release code using the existing runtime and generating a stand-alone EXE that would have been the cat's meow, IMHO.

Thanks for reading.

kevin

Kevin Moore
Wednesday, January 28, 2004

Well, ya know, that's what Delphi is for. Create a big nice all-in-one executable.

I've even made a file-transfer-in-the background program in Delphi that installs the dot net runtime for those of my customers that don't have it yet and need some other guys dot net apps.

Mark Boler
Wednesday, January 28, 2004

The same can be said of Java, right? Or python. Or lisp. Or bash (ok, that's pushing it). These are all interpreted languages. In each case it seems nobody spends time trying to package the virtual machine into a single executable.

Kartik Agaram
Wednesday, January 28, 2004

Yeah, Joel's rant should be used as a sales promotion for Delphi/Win32. Most of my installs with Delphi are just glorified file copies. Rarely does a dll need to registered (COM is so crap why use it anyway) or massive windows updates need to be performed.

Craig
Wednesday, January 28, 2004

Python code can be compiled into a single EXE + DLLs, so it will run on a Win32 machine with no Python install. Check google for Py2exe.

Pity it doesn't work for *nix systems, but those often have Python installed (or users knowledgeable enough to install it).

Fred
Wednesday, January 28, 2004

> The same can be said of Java, right? Or python. Or lisp. Or bash (ok, that's pushing it). These are all interpreted languages. In each case it seems nobody spends time trying to package the virtual machine into a single executable.

But maybe some people would be interested in having this option? It certainly sounds like it.

To me that sounds like a market opportunity for a language developer, rather than we don't need it because others do don't it either.

S. Tanna
Wednesday, January 28, 2004

Even if you don't use Py2Exe, with Python you at least have the option of installing a drastically cut-down Python installation to the user's machine. With a bit of work you could get it down to under a meg of binaries and just whatever standard libraries you actually use.

Part of Joel's rant is, while you could do a similar cutting-down with .NET, Microsoft's EULAs don't allow you to legally distribute anything but the whole-honking .NET Framework, even if you use only a small percentage of everything the APIs support.

Mister Fancypants
Wednesday, January 28, 2004

"Yeah, Joel's rant should be used as a sales promotion for Delphi/Win32"

Hmmm... maybe the best way to ENCOURAGE MS to provide this feature is for Delphi to use that rant.

I've been telling my Delphi rep this for a long time.

The real Entrepreneur
Wednesday, January 28, 2004

Actually there is still some form of linker called ‘al’. But of course it is intended to produce dynamically loaded assemblies from files compiled to modules.

Most evidently .NET with all its functionality and complexity is designed to be an integral system level API rather than just a runtime supporting an application. So it is hard to expect any optimizations in this field. Nevertheless as it is announced to be the native API of Longhorn at that time all problems with pre-installing .NET should be gone.

Janusz Szpilewski
Wednesday, January 28, 2004

"as it is announced to be the native API of Longhorn at that time all problems with pre-installing .NET should be gone. "

Where was it announced?

Which VERSION of .net will be preinstalled on Longhorn?

The real Entrepreneur
Wednesday, January 28, 2004

"Which VERSION of .net will be preinstalled on Longhorn?"

At least version 2.0 (no idea whether it will come with prior versions install as well).

However, Longhorn isn't entirely built in .NET. However, the new GUI system and the new shell are (if I heard right).

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, January 28, 2004

"However, Longhorn isn't entirely built in .NET. However, the new GUI system and the new shell are (if I heard right)."

The Longhorn that actually hits shelves may be very different than promised. Microsoft has a long, long history of promising tremendous change and delivering a spiffy polish on legacy code.

Dennis Forbes
Wednesday, January 28, 2004

S. Tanna wrote:
"To me that sounds like a market opportunity for a language developer, rather than we don't need it because others do don't it either."

Oh, absolutely. I didn't mean to suggest it wasn't needed, just to point out that perhaps Joel's rant could be generalized.

Kartik Agaram
Thursday, January 29, 2004