Re: dotnet platform support / gnu config

[Guido Draheim]

Guido Draheim wrote:
> Bob Friesenhahn wrote:
>
> > On Thu, 11 Sep 2003, Guido Draheim wrote:
> >
> >
> > > * short
> > >
> > > The world has changed - there are commandline tools for unixish systems
> > > that take a C program (not C#!) and compile them into a MSIL binary or
> > > library. This makes it a valid crosscompile target for free software.
> >
> >
> >
> > Your very *long* posting failed to describe in which way the dotnet
> > target varies from traditional targets.  Microsoft's Visual Studio
> > handles building for .net very similarly to traditional binaries.  It
> > uses "normal" object files and "normal" DLLs.  These apparently
> > "normal" files have had their format extended to support .net.  
>
>
> The nt/win9x exe/dll are container formats based on the pe/coff format.
> [...]
>  ARM native code. With dotnet, an IL intermediate code is put in. 

So much for similarities ;-) which is actually correct since the
compiler suites are designed to allow to take over as much of the
original (build) infrastructure but just creating IL intermediate
code instead of whatever-cpu native code, put into the executable
section of the program/library. The programmer can handle these
targets very similar to any other crosscompile target.

The differences are about the interface descriptions which allow
other dotnet languages to reuse code from any other language. That
is similar to c++ libraries where you can get back the complete
call synopsis from the library function call exports, instead of
just an entry adress of the function call export. Dotnet assemblies
do usually export and describe class types as well. Similar to
java jars you can link with them without a need for a header file.

In a way, the dotnet DLLs are not "normal" DLLs at all, but they
could be best compared with a pe/exe header in front of a .jar
file. In fact, pnet `cscc -mjvm` will create dotnet binaries which
have the very same layout with all interface descriptions and pe/exe
stub but the actual executable section contains java jvm-IL instead
of dotnet-IL - and requires a jvm/jre for execution.

From a linker perspective, these parts are orthogonal, one is
the type of executable section which the runtime linker may need
to relocate and weave with call adresses of functions of the runtime
system (in dotnet they are not only relocated by reassembled) - and
the other is the container format with sharedlib declarations and
sections used by both compiler linker to bind parts (ld -o .so) and
also  the runtime linker when to resolve function calls dynamically
by name (ldso).

-- guido                                  http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)