|
From: | Guido Draheim |
Subject: | Re: dotnet platform support / gnu config |
Date: | Thu, 11 Sep 2003 18:42:13 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 |
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)
[Prev in Thread] | Current Thread | [Next in Thread] |