Syntax10.Scn.Fnt ZeStyleElemsAlloc TitleSyntax24.Scn.Fnt0Syntax12i.Scn.Fnt Ze Author) Z0*LineElemsAlloc Ze Header1Syntax16b.Scn.Fnt Syntax12.Scn.Fnt Zx  Standarde Header1 Syntax14b.Scn.Fntx  StandardI1e Header1x  StandardI1e Header1  Zx  StandardI1 Ze Header1 Zx  StandardI1 Ze Header1 Zx  StandardI1z Ze Header1Syntax12b.Scn.Fnt,x  StandardI1 Zxw List1\_ Ze Header1) Zx  StandardI1 Zxw List1 MB w ? 3 O ?1B G, 1 $} B;dc(=& )'  Y "1B3J@ $ Ze Header1  Zx  StandardI1y Ze Header1 Zx  StandardI1 8Z Ze Header1  Zx  StandardI1 Ze Header1  Zx  StandardI1 Ze Header1 Zx  StandardI1h Ze Header1  Zx  StandardI1 Ze Header1 Zx  StandardI1, Ze Header1  Zx  StandardI1Q Ze Header1  Zx  StandardI1 Ze Header1  Zx  StandardI1: Ze Header1 Zx  StandardI1 Ze Header1 Zx  StandardI1? Ze Header1 Zx  StandardI1F"]pQ  Ze Header13x  StandardI1j Zx ΗColumns4 Zx  StandardI1* Zxw List1=#ParcElemsAlloc$.TableElemsAllocSyntax10.Scn.Fnt&Courier10.Scn.Fnt       Y/table Module(s) size in bytes Adapt 1076 ArchiveElems 12144 Beautifier 36326 DA/IS/SAFiles 24918 DOS 1741 Easter 1587 FontToBDF 7319 Mailer 27392 Miscellaneous 10724 Oberon-D 711473 PostIt 26282 RandomNumbers 1454 Swarm 5683 TeX 8348 Unix 35558 X11 46266 ======= 958291  Ze  PageBreak Ze Header18IndexElemsAlloc#Syntax10.Scn.Fnt References  Z K4 0Referencesu\W Oberon for GNU/Linux with Linz extensions Robert Lichtenberger, March 1999  1. Foreword Oberon V4 is heavily used in teaching and research at the Johannes Kepler University in Linz, Austria. Numerous enhancements have been added to the standard Oberon V4 (also known as ETH Oberon). These enhancements led to the terms "Oberon with Linz extensions" and "Linz Oberon V4". Until now Oberon systems with Linz extensions were available for Windows and PowerMac only. In April 1996 I decided to port a few of the most helpful enhancements from Linz Oberon for Windows to the existing ETH Oberon for Linux. This task proved to be rather difficult as well as extremly interesting. I decided not to stop porting - Linz Oberon for Linux was born. This document tries to describe the steps that were necessary to port and integrate the various Modules from other Oberon versions. Most often the Windows version has been used, except in some rare cases where other versions (PowerMac, ETH HP-Oberon) were a better point to start from or a completely new Module had to be written. Oberon for Linux with Linz extensions has been done in the hope that it will further push the idea of free software in general and the use of Linux and Oberon in particular. 2. Porting Elements One of the most powerful aspects of Oberon V4 are TextElements. For a detailed description of TextElements see [MKo95] and Elem.Guide.Text. Text Elements were completely portable. ClockElems and IconElems (also known as the Oberon Walker) were affected by the load problem (see below) TextFrames / Texts The original TextFrames - Module in ETH Oberon for Linux does not support the Keys Up/Down, PgUp/PgDown, Home and End. Since Oberon is so much text-oriented, the integration of TextFrames.Mod from Windows Oberon improved the user-friendliness a lot. The new Texts Module (also taken from Windows) supports Directories (i.e. a name can begin with the $ - sign) The TextPreview - Module was also taken from Windows. TextPreview allows you to preview pages before printing them. Compiler A lot of new packages (e.g. the Heapinspector) need the full reference information provided by Module Ref. While the Ref-Module is completely portable the Compiler itself is not. Porting the compiler from Windows needed adaption of iOPC.Mod and porting BootLinker.Mod/Modules.Mod as well. A strange phenomenon can be observed in iOPC.Mod: In certain code generating routines like NewSys, NewArray, NewRec, Call , etc. an additional Assembler statement ADD ESP, 8 has to be generated in order to produce runnable code for Linux. This task was very time-consuming since incompatibilities between the Compiler and Module-Loader lead to an inoperable system immediately. A second update of the compiler was needed when the GIF - Module showed a compiler weakness. Together with the new compiler a new Element, called TreeElement was ported. TreeElements give a quick overview over Types and Procedures of a Module. Dialogs The Dialogs-Package [Kna94] adds graphical user interfaces to Oberon. It was completely portable using the Bitmaps - Module that is based on the Display - Module only. Kepler The Kepler-Package [Tem93] is an experimental tool for editing two dimensional line drawings. It was completely portable. Miscellaneous / Utilities New Modules not found in other distributions  Adapt: This module allows special keyboard adaption without using xmodmap from the command-shell. DOS: The module DOS allows importing of files from MS-DOS filesystems and old Windows Oberon files. TeX: Module TeX has been implemented which provides a simple means of pretty printing with TeX, the standard Unix program for text formatting and type setting. However TeX only provides very basic features. Modules taken from other Oberon versions All modules in this section were completely portable and taken from Windows if not mentioned otherwise. Since oberon is constantly developed this list may not be up to date.  AsciiCoder: The AsciiCoder is the basic means of portable text encoding under Oberon V4. Batch: Batch adds Batch-processing functionality to the Oberon System. Beautifier: The beautifier is not part of the standard Windows distribution. It formats Oberon-2 source code in a very nice way. Compress: Compress is a filepacker Count: Counts lines, statements and character in an Oberon-2 module CrazyFiller: Filler viewers are painted with Mandelbrot sets. Decoder: The Decoder uses the extended reference information to decode objectfiles. A difference in the behaviour of Texts on Windows and PowerMac has been detected by porting the Decoder. Documents: Documents allows to open various files with only one comman Documents.Open. Distributor: Distributor is a utility for compiling Oberon distributions Draw: 2D drawing utility Dsp: Dsp offers screen output in low-level modules Easter: Calculates date of easter of any year. Not included in Windows. EditKeys: EditKeys allows to define keyboard shortcuts for often needed actions. Film: See Film.Text for details. Find: Finds textpatterns and imports in Modules FontEditor: allows modification / creation of Oberon-Fonts Hex: a hex-editor Interface: Customizing interfaces of Modules IS/SA/DAFiles: These modules are used for teaching and present a subset of Files with index-sequential, serial or direct access behaviour. LineSorter: Sorting lines. Lines: Lines extracts lines containing a certain pattern from a text. Mailer: Taken from HP-Oberon. Provides access to UNIX mailboxes. Make: Make topologically sorts a set of Oberon source file names according to their import relationships Miscelleaneous: The module Miscellaneous was taken from HP-Oberon mainly to have the X-Window clipboard facility available. To provide compatibility with both other Oberon for Unix versions and Oberon for Windows/PowerMac the Clipboard part has been copied into a new module Clipboard. PostIt: PostIt is not part of the Windows distribution. It allows to create, load and store little notes. Put: Oberon's answer to printf RandomNumbers: Returns random numbers of various kinds Screen: Screen lets you switch between one-track and two-track mode Sets: Extended (unlimited) sets Shell: Opens a session using rlogin Sort: Sorts lines in a text alphabetically SortDemo: Demonstrates various sorting algorithms Split: Splits a big file into smaller parts. Statistics: Various statistical functions StatusViewer: Opens a viewer that shows current directory, date and time. Not part of Windows Oberon. StringSearch: Various string search algorithms Strings: Strings provides a set of operations on strings Swarm: Graphical simulation of a bee swarm. Not part of Windows Oberon. TarDump: This module should dump a standard Unix Tar file. Timer: This module was designed for measuring the execution times of procedures Trace: Trace provides means for switching debugging output on or off. UUDecoder: UUDecoder decodes uuencoded files. DirectoriesOne of the most important improvements of Linz Oberon is the introduction of Paths and Directories. Original ETH implementations only supported a flat directory structure or the path naming system of the underlying operating system. This situation led to much incompatibilities among various implementations. The path delimiter in Windows is \ for example, so / was used as the character for Command-Line options whereas in Linux it is exactly the other way round. This led to the necessity of adapting a lot of Modules that used paths and/or options. (e.g. Compiler, the Make-Utility, MyUI, etc.) As of autumn 1997 pathnaming has been unified by using / as the path delimiter and \ as the option character. (See also Directories.Text) This unification implies that a Module exists that encapsulates different filesystems. This module is highly system-dependant. The Linux-Version of Directories uses standard Unix system-calls (stat, chdir, mkdir, rmdir, rename) as well as calls to the GNU C-Library (getcwd, opendir, readdir). The PowerMac - version was chosen as a starting point for the implementation of the Directories - Module, since the Windows - version was hard to understand. To fully support the new mechanisms a few changes had also to be done in the Modules Files and System. o Files.Delete, Files.Register and Files.Rename call Directories.notify. o Files.Old now accepts filenames starting with the $-sign. o Files.Dir is mapped to Directories.This. o System.ChangeDir and System.Directory now accept filenames starting with the $-sign. o System was enlarged by the procedures CreateDir, DeleteDir, ParentDir, ShowDir and StartupDir Network-SoftwareTCP In order to make any of the network programs available under Linux the TCP - Module had to be ported to Linux. This module is also highly system dependant and many routines had to be written from the scratch. TCP under Linux uses GNU LibC sockets. Telnet The Telnet - Modules were completely portable but contained a bug that made it impossible to connect to Linux machines. Besides Telnet was also subject to the load problem described below. Web-Browser The Web-Browser is still under development but a version is already included. Integration into linux was fairly easy as soon as the necessity of a volume name in URL's was removed. The Web-Browser uses Pictures, so porting Pictures was a requirement for using the Browser. NetNews The Usenet-Newsreader [Ham97] was completely portable. FTP The FTP-Package [Obi96] was completely portable but showed very poor performance under Linux because TCP.Available() returned a maximum of 1024 Bytes thereby limiting the number of bytes read at each handler invocation. The constant FTPB.taskTime had to be set to 0 as well to keep the receiver task from sleeping after each handler invocation. HeapInspectorThe Heapinspector [Ram97] required only little corrections to the interface of the Kernel. Pictures was also a requirement for porting the Inspector. FileManager The Filemanager-Framework [May95] adds GUI - functionality to the filemanagement in Oberon. It was completely portable, although a bug fix was necessary in FMSysDev.GetPath: A call to Strings.Cap which transformed filenames to uppercase always had to be removed. Panels Panels [Ert98] provide GUI elements that are more flexible than Dialogs. They were completely portable. Pictures Porting the Pictures Module to Linux / X11 was the most difficult task of the whole project. Since X Window is designed to run on a very wide variety of hardware platforms (i.e. different types of screen hardware) image manipulation is extremely complex. In theory, every good X11 application should work on 12 inch monochrome X-terminals as well as on 21 inch high-end graphic workstations. In addition colors are often very rarely available under X. The original ETH implementation of Oberon V4 only needed 16 colors and was designed for Pseudo-Color displays (i.e. 4 to 8 planes or 16 to 256 colors) only. Most linux boxes nowadays run on graphic cards with much higher capacity and most X-Servers are implemented as TrueColor servers (i.e. 16 bit color depth or more). For a detailed description of X Window's server typed see [Nye93], pages 193ff. The original ETH implementation however did not support TrueColor servers, defaulting to monochrome mode. This led to unrecognizeable Popup _ Elements. So in a first step, the X11-Module and Display-Module were changed to make Oberon run on TrueColor servers: Instead of allocating 16 read/write color - cells as is done with PseudoColor servers, Oberon serves color requests (Display.SetColor) by matching them to the closest color available. The same technique was used when implementing Pictures for TrueColor servers. Since one cannot allocate read/write colorcells on TrueColor servers, every (r, g, b) - triple is mapped to the closest color available while drawing. On a PseudoColor machine the necessity of many colors (e.g. for Bitmaps with 24 bits per pixel) cannot be satisfied. A (relatively small) standard palette has to be allocated and used for all pictures. Oberon uses multiple bitplanes for highlighting (e.g. selecting text). For a detailed description of this technique see [Nye93], pages 205f. This technique introduces a minor drawback: The amount of colorcells that are allocated must be a power of 2. Most PseudoColor displays will have 256 colors but since the windowmanager will always need some colorcells, the maximum amount of colorcells that can be allocated by Oberon are 128. If less than 128 cells are available (e.g. due to other applications or windowmanagers that use many colors) oberon fails to start, telling the user to start oberon with parameter -c. If Oberon is started with parameter -c it allocates a private colormap. If the allocation of 128 colorcells was successful, the first 16 colors are used as the standard oberon colors, the next 100 cells are used for the 4-4-3 (r, g, b) palette used in the Pictures-Module, the last cells are not used. The procedure ConvertText uses Display.GetChar to obtain character patterns from the chosen font. We refrained from implementing an Optimization as is done in Display.CopyPattern. This mechanism uses X Window Fonts to speed up displaying of text. However the mechanism is rather complex and InsertText will not be called often enough to allow a significant speed up. The reduced amount of colors available on PseudoColor displays required the implementation of a dithering algorithm. On monochrome displays dithering is also done to enhance the picture quality. Memory management is also an interesting point in the implementation. Since the oberon heap is usually chosen to be rather smallsized (4 MB default) pictures are not held within the Oberon heap. Instead a call to Kernel.malloc allocates "external" memory for each picture's raw data and a finalizer frees this memory by calling Kernel.free. Printing pictures to a postscript printer was another challenging task. We took the output that xv [Bra89] generated when converting a picture to postscript. It provided a good starting point for adapting Oberon.Header.ps and PS.Mod. Pictures are always printed 24 bpp thereby also supporting color printers. The procedures SetScanLine and GetScanLine that were added to the interface of Pictures for better support of GIF and JPEG graphics were completely portable. GIF, JPEG and XBM were completely portable. The load problem A number of Modules that use Oberon.Tasks to run in the background were ported from Windows. Some of them did not use the field Task.time to delay the next invocation of the task's handler. This led to 100% CPU load which is undesireable on Linux machines. Even under Windows such a behaviour may be considered to be against the spirit of Oberon. Therefore Icon- and Clock-Elements, Telnet and the Color-Module were patched. In the FTPB-Module however no delay was introduced for the receiver task in order to allow transmission to be as fast as possible. Oberon-D Oberon-D [Kna96] adds database functionality to the Oberon-System. Oberon-D was almost completely portable. Only the different exception handling mechanisms of Windows and Linux had to be managed. Porting Oberon-D led to the implementation of an extended Exception handling mechanism for Linux that works similiar to that under Windows. Debugger The Debugger currently contains a number of bugs in the Windows version already. The version included here is to be considered alpha therefore.  Profiler The Profiler has been enhanced and is no longer portable. Exception handlingOberon-D and the Debugger arose the necessity of an exception handling mechanism that is similar to Windows. Therefore the Unix-Module was augmented by the types ContextRecord, ExceptionPointers and ExceptionRecord which are the same as under Windows. A procedure type TrapHandler exists as well as a Procedure InstallTrapHandler which allows to install a new TrapHandler, returning the one that was installed before. The Procedures are not installed as TrapHandling procedures directly but are called via Unix.TrapManager. There is still a difference between Oberon for Windows and Linux: Recovery must be done explicitely in the trap-handling procedure by calling Kernel.siglongjmp(...). Usually the trap-handling procedure will jump back to Oberon.Loop, but Oberon-D for example will jump back to the instruction that caused the trap in order to try once more to load the formerly illegal dereferenced object. This adaption of the low-level exception handling facilities allowed porting of Oberon-D with only a small number of changes in the code. Further adaption of the mechanism had to be done to provide compatibility with the new GNU C-Library: The signal handler has to be reinstalled explicetely each time it is invocated. Font machinery The font machinery was revised so that auxiliary .Scn.Fnt and .Pr3.Fnt - files are no longer needed. For screen fonts the metrics are now retrieved by using Xlib calls. For printing any installed postscript font can be used. For both types of fonts mapping can be done via a file Font.Map (see Fonts.Text for details). Changes in low level ModulesConsole The interface of module Console has been adapted to that of Windows. Display Beside the fixes that were necessary for Oberon to run on TrueColor X servers (see Pictures) a version for monochrome systems has also been implemented. Fonts The font mechanism was adapted to access any X-Window font without the need of a .Scn.Fnt - file. Fontmapping is also possible thereby allowing different users to have different font layout schemes. Input Input.TimeUnit is now a constant. Kernel In order to make the HeapInsepctor portable the Records Blockm4Ptr and Blockm4 were renamed Block and BlockDesc. Block is now exported. Notifier-Queues were added as described in [Kna96]. Extensions neccessary for the implementation of Threads were implemented in the form of procedure variables that are set by Module Threads and allow to stop, resume and enumerate threads as well as enumerate on thread's stack. Garbage collection was taken from windows and adapted to multiple stacks. Printer Color-Printing was taken from HP-Oberon and adapted slightly. (Different printing commands) PS The postscript printer driver was adapted to be able to print Pictures and uses standard Postscript fonts now. Unix A new exception handling mechanism has been implemented (Procedure TrapManager). X11 Changes in the X11-Module were needed for the implementation of Pictures. They are documented there. Since Xlib is not reentrant all calls to the XWindow system that were formerly procedure variables have been changed to procedures that are protected by a semaphore. 3. Differences between Windows and Linux Oberon V4 On of the main aims of the project was to unify Oberon for Linux as far as possible with Oberon for Windows. This section concentrates on differences that still exist. Interface comparison We took the following low-level modules and compared their Interface using Browser.ShowDef and Find.Diff: Console Kernel PrinterDriver Directories MenuViewers Reals Display Modules System Edit Oberon TextFrames Files ParcElems TextPrinter Fonts Pictures Texts Input Printer Viewers The following differences could be found: - Under Linux, there is no procedure Console.Real - Display.Map has two integer parameters in Linux but only one in Windows. This does not matter however, since both return always 0. - Input.TimeUnit is CONST in Windows but VAR in Linux. - The Linux Kernel-Module export a procedure type KeyCmd and an array of KeyCmd called FKey. These provide a means of binding often used commands to function keys. Kernel under Linux also exports low-level exception mechanisms different to those under Windows: Types Sigjmpbuf and SignalHandler exist and procedure variables setjmp, sigjmpsave, siglongjmp are bound to their corresponding system call equivalent. A procedure InstallSignal allows to install a TrapHandler for certain exceptions under Linux. Finally trapEnv is an array used for saving the system-state during exceptions. Additional memory can be managed under Linux via the Routines Kernel.malloc and Kernel.free. The procedure variable getadr which is used to bind procedure variables to system calls has a different interface under Linux than under Windows. Windows uses the procedures LoadLibrary, FreeLibrary and GetAdr for call to API-functions and .DLLs. The Oberon for Linux Kernel does not yet support Threads. Passive waiting for events is done in Oberon for Linux using Kernel.Select and readSet / readySet. - Oberon.User is 12 bytes long under Linux compared to only 8 bytes under Windows. - The Windows version of Printer additionally exports a procedure GetChar. - The System - Module under Linux additionally exports ClearLog, Execute and Suspend. See LinuxOberon.Text for a description of these commands. Windows System - Module has procedures get and set, used to access the Windows registry and Unload and enhanced Module unload mechanism, that will probably be integrated in a later version of Oberon for Linux. - Directories handle paths as ARRAY 256 OF CHAR because extended two filesystem filenames can be up to 255 characters. Windows uses Directories.LocalToURL and Directories.URLToLocal to map Oberon filenames to Windows filenames. This is not neccessary under Linux. Modules not part of Windows Oberon Some of the Modules in Oberon for Linux are taken from other Oberon versions (HP-Oberon, ETH Oberon for Linux, etc.) or are distributed seperately and are not part of Oberon for Windows. These are listed below:  References [Ert98] C. Ertl: Elems [Ham97] P. Hamader: NetNews - A NNTP Client for Oberon [Kna94] M. Knasmller: Oberon Dialogs - Users' Guide and Programming Interfaces Report 1, 1994 [Kna96] M. Knasmller: Adding persistence to the Oberon-System. Report 6, 1996 [May95] C. Mayrhofer: File Manager User's Guide [MKo95] H. Mssenbck, K. Koskimies: Active Text for Structuring and Understanding Source Code Report 3, 1995 [Nye93] A. Nye: Xlib Programming Manual, O'Reilly & Associates Inc., third revision, 1993 [Obi96] G. Obiltschnig: FTP - A File Transfer Protocol Client for the Oberon System. [Ram97] M. Rammerstorfer: Heap-Inspector