[Mono-list] ngen and native executables

[Erik Poupaert]

Hi

It looks like the ngen.exe project is pushing things in the right direction.

Both Java and DOT.NET fail on one account: You can't deploy self-contained,
native executables with all dependencies included and no (unreasonable)
external dependencies. You're simply forced to drag along an ever-changing,
ever-growing runtime and classlib, that creates a dll-hell of its own kind.

Every developer that I know, longs for the same simple solution: being able
to deploy one, unbloated, and self-contained executable.

Proprietary vendors, however, do not wish to provide such solution.

They see their runtime as a platform that must stay separate from your
application. They always tend to invert things. For example, I see a
relational database as a persistence helper, i.e.,  some kind of library
that I would include in my server-application. Microsoft and Oracle see it
the other way around: the rdb is the executable, and your application is cut
into stored procedures and runs in their executable. The same thing holds
true for web servers, ejb containers, and so on.

This is the platformization problem: The problem in which your application's
logic is cut into little pieces and inverted to a proprietary process. It
leads to major problems, because you can only reasonably invert your
application to one other process. If your stored procedure runs in the
Oracle container, how can it run in the Weblogic ejb-container at the same
time, while conforming to the needs of the IIS-container as well? The
solution would be to include all foreign logic into your own container. Only
open source is sufficiently humble to put the needs of the user first and to
provide this solution.

My question is now: Since Mono is open-source, why do you play the
platformization game? Why should any application be invoked by Mono, and not
the other way around?

Turn things around, and the solution not only becomes brilliant, but it will
beat proprietary DOT.NET vendors' solution hands down. Mono would have
strong, compelling advantages, that they cannot or will not provide, and
certainly not within a reasonable time frame:

- There would be no need to download and drag around a large runtime and
classlibs;
- there would be no versioning problem of the runtime and classlibs, because
every deployed executable would have its own;
- by removing unused symbols, executables only carry with them the pieces of
runtime they actually need; I would suggest using the UPX executable
compressor as well;
- Executables run by double-clicking them; no "java -r app.jar" and other
bs.
- Iteroperability with Java, C++ code would not be a concern, because the
executable could natively invoke gcc/gcj-produced and included dependencies.

Get also rid of the notorious cygwin.dll and let developers produce native,
all-included executables on Linux and Windows. You will push proprietary
DOT.NET vendors out of the market by doing so.

The alternative is that you provide a runtime cum classlibs download, while
Microsoft includes theirs by default in the OS.

The window of opportunity is not large, and now that the DOT.COM hype has
ended, don't expect AOL to take over your remains for $4 billion dollar.