It is assumed that you have downloaded and installed the compiler properly (including the possibly editing of the global path variable) so that when you type into the console $Oberon ($ denotes the prompt) the compiler responds with its version number and the parameter info:

$Oberon
Obscan Release $Date: 2002-12-12 00:42:44+01 $ ($Revision: 1.12 $)
Obgen Release $Date: 2002-12-12 00:42:44+01 $ ($Revision: 1.20 $)
Obparse Release $Date: 2002-12-12 00:42:44+01 $ ($Revision: 1.21 $)
Oberon for .NET: JG, TF, PK, HH, RG, TL
Homepage: http://www.bluebottle.ethz.ch/oberon.net/
Usage:
Oberon <FileName> [/r:<assembly>] [/cls] [/noasm] [/v] [/dll]

Now, write and compile your first program:

1. Open your favourite editor and type in the following lines of code.
   
   

   MODULE HelloWorld; BEGIN WRITELN("Hello World"); END HelloWorld.

   
   
2. Save the code in a file with the name 'HelloWorld.mod'.
   
   
3. Open a console and change to the directory where the newly created file 'HelloWorld.mod' is stored in.
   
   
4. Compile the file by :
   
   

   $Oberon HelloWorld.mod

   
   The compiler yields the name of the new executable file (HelloWorld.EXE) and indicates whether the compilation process was successful (done) or not.
   
   

   Obscan Release $Date: 2002-12-12 00:42:44+01 $ ($Revision: 1.12 $) Obgen Release $Date: 2002-12-12 00:42:44+01 $ ($Revision: 1.20 $) Obparse Release $Date: 2002-12-12 00:42:44+01 $ ($Revision: 1.21 $) Oberon for .NET: JG, TF, PK, HH, RG, TL Homepage: http://www.bluebottle.ethz.ch/oberon.net/ Invoking ILasm with (args=HelloWorld.IL)... done. -> HelloWorld.EXE generated.

   
   Besides the EXE-file a second file is created, the IL-file (Intermediate Language). The reason for this is that the Oberon for .NET compiler itself translates the MOD-file only into an IL-file. The further translation of the IL-file into an EXE-file is the task of the ILasm (IL Assembler) which is invoked automatically by the Oberon compiler.
   
   
5. Run your HelloWorld program:
   
   

   $HelloWorld.exe

The following list lets you download the syntax-highlighting files for a couple of different editors.
If there is no syntax-file available for your favourite editor, please write one and contribute it! Send us your syntax-file.

Editor	Syntax-Files	Contributed by
TextPad	Oberon for .NET syntax file Oberon for .NET compiler messages syntax file Common Intermediate Language syntax file	tlozza@student.ethz.ch
EditPlus	Oberon for .NET syntax file	johnny@grob.org

The following answers are given by the Internal Working Document on the Common Language Infrastructure (CLI).

result = value1 DIV value2 satisfies the following conditions:
result  = value1 MOD value2 satisfies the following conditions:

Please note that this definition of DIV and MOD differs from the definition given in [M. Reiser, N. Wirth. Programming in Oberon. p. 36]:

Example:

	Oberon for .NET	Native Oberon According to Reiser & Wirth.
-5 DIV 3 =	-1	-2
-5 MOD 3 =	-2	+1

So far, it does not. The problem is that the Oberon for .NET compiler invokes the ILasm (IL-assembler) in order to translate the IL-code (which is produced by the Oberon compiler) into an executable file (.exe file).
Unfortunately the ILasm has not been implemented on Mono yet.

Compiled Oberon programs work under Mono, though. This is due to the fact that the .NET exe-file format is portable (therefore it is called PE format - Portable Executable). So, compile your Oberon program under Windows and run it under Linux!

Please inform yourself on the Mono homepage about the latest news since the Mono-people are making great progress and the information given here might be outdated soon.

The following list presents all Oberon for .NET basic types and gives information about the internal mapping and their ranges.

Oberon .NET Type (T)	IL Type	Bits	MIN(T)	MAX(T)
BOOLEAN	System.Boolean	8	N/A	N/A
CHAR	System.Char	16	N/A	N/A
BYTE	System.Byte	8	0	255
INTEGER	System.Int32	32	-2147483648	2147483647
REAL	System.Double	64	-1.79769313486232E+307	1.79769313486232E+307
SET	OBERON.SET	32	0	31

The compiler issues this message if it cannot find the OBERON.DLL file in the working directory (the directory where you actualy are and invoke the compiler). This is not a problem as long as the program to be compiled does not use the SET type. Otherwise, OBERON.DLL has to be copied into the working directory.

For an integration into Visual Studio .NET the compiler had to be rewritten (or at least big parts of it since the compiler is not broken up in a  front- and a back-end part). This is currently not an issue.

Active Oberon compiler is the former name of the Oberon for .NET compiler.
History:
The Oberon for .NET compiler project was launched in the context of the more general approach of introducing a new paradigm into Oberon - the paradigm of active objects. A first version of the compiler was called Lightning Oberon in relation to the code-name of the .NET framework. Later on, this name changed to Active Oberon since the paradigm of active objects was supported by the compiler and more emphasis should be given on that.
Since several problems occured with the implementation and different techniques had to be tried out, the compiler never reached the full level expressiveness. Therefore, a new project with the codename Zonnon was launched with the experience of the Active Oberon compiler. This one, on the other hand, was renamed to Oberon for .NET compiler and redimensioned in order to achieve the expressiveness of Oberon-1 but not more, i.e. the concept of active objects was dropped.

Currently there are no plans to integrate the XSC extensions into Oberon for .NET. Although, the experiences made with Oberon-2, Oberon-XSC and Active Oberon will reflect in the design of the new programming language with the codename Zonnon.

All variables are initialized to 0 of  the appropriate type, i.e. for example:

Type	Initial Value
BOOLEAN	FALSE
CHAR	ORD = 0 (ordinal number) Note: A char can never be equal to '' (without a space) since it always represents a character.
BYTE	0
INTEGER	0
REAL	0
SET	0 (empty set - no bits set)
System.String	NIL and not "" since it is an object-type.

Lets consider the following 2-dim array in Oberon:
a: ARRAY n OF ARRAY m OF <base-type> (equivalent to the notation: ARRAY n,m OF INTEGER)

The internal representation of a as jagged array looks as follows:

addr0	->	elem0 ... elemm-1
. . .	->	. . .
addrn-1	->	elem0 ... elemm-1

On the contrary, a implemented as real multi-dimensional array looks internally as follows:

elem0,0	...	elem0,m-1
. . .	. . .	. . .
elemn-1,0	...	elem0,m-1

Originally, jagged arrays were implemented in Oberon for .NET. But due to their incomplete implementation and flaws in the design of the compiler it was decided to replace jagged arrays by multi-dimensional arrays. Release 2.x of the compiler is the first release with multi-dim. arrays.

Please note the following consequences resulting from the new implementation:

TYPE
    string = ARRAY n OF CHAR;
VAR
    s: ARRAY m OF string;

-> s represents a 2-dim. m x n array. Therefore it has to be referred to as s[0..m-1, 0..n-1] which denotes a single character.
s[0..m-1] will be rejected by the compiler since s is not a 1-dim. array.
If you want s to represent an array of strings, use instead: s: ARRAY m OF System.String.

When the compiler yields the message "signature required" it asks for some signature information in order to check the types (and guarantee type-safety).

Example:
System.String.Concat{(System.String, System.String):System.String}(a, b);

The signature is enclosed in curly braces, it gives: The function Concat takes two parameters of type System.String and the result-value is of type System.String as well.