dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AW: [DotGNU] Introduction


From: Carsten Kuckuk
Subject: AW: [DotGNU] Introduction
Date: Wed, 27 Mar 2002 12:01:00 +0100

Here are some suggestions for important but unpopular glue-stuff

(1) Each .NET module (hello.exe) contains a small piece of 80386 code known
as the PE stub that simply calls ta function named _CorExeMain() exported by
the mscoree.dll. The WINE project is able to load and execute PE
executables. If WINE executes a .NET module, it would try to find the
mscoree.dll and run its _CorExeMain() function. WINE doesn't have this DLL
yet. _CorExeMain() simply starts the CLR which in turn starts JITing the IL
code. If somebody used CYGWIN, wrote a DLL with the name mscoree.dll that
simply exports a function named _CorExeMain() which in turn would fire up
PortableNET, then PortableNET would be seemlessly integrated in WINE. People
using WINE could double-click on a .NET executable and use PortableNET to
run the code. You can find more information about the plumbing in the two
books
- Applied Microsoft .NET Framework Programming, Jeffrey Richter, Microsoft
Press
- Inside Microsoft .NET IL Assembler, Lidin, Microsoft Press.

(2) Having Java and C# around is a real PITA, especially as they are so
similar. If you take out C#-Attributes and Delegates, they are almost
identical, and programs written in this C# subset would be isomorph to
programs written in Java minus inner classes. So if somebody wrote a
Java-to-C#-and-back translator which would use some set of tables to rename
some framework classes when doing the switch, suddenly people could write
code in Java and have it translated to C# and the other way around. This way
Java programmers could contribute to DotGNU, too, and DotGNU classes could
be used in a Java context. The way to approach it would be to
-Imlement the C# CodeDOM classes (System.CodeDOM) and use them for
representing the abstract syntax tree (AST)
-write a Java parser that creates a CodeDOM representation
-write a C# parser that creates a CodeDOM representation
-write a Java Code Emitter that dumps a CodeDOM representation as a Java
source file
-write a C# Code Emitter that dumps a CodeDOM representation as a C# source
file
-Trap#1: Each AST node should be ammended by a field representing the white
space that was present in the source-code before it. This white space should
be emited later. In this way, comments would be preserved
-Trap#2: A translation table needs to be defined and used that can translate
Java-Framework-Classes into equivalent C# Framework classes.
Relevant Literature:
- Java Language Specification
- Microsoft C# Language Specification, Microsoft Press, ISBN 0-7356-1448-2
- See also: ECMA-Standard 334: C# Language Specification,
http://www.ecma.ch/ecma1/STAND/ECMA-334.htm

If somebody wrote this second "Code Morpher", there would be a way to move
between the two worlds on a source code basis which is dearly needed for
ISVs in order to avoid a lock-in.

Just my two cents.

Carsten Kuckuk <-- not having anything to say in this project



reply via email to

[Prev in Thread] Current Thread [Next in Thread]