Leigh C. Make Way for Oberon/F, 1997

Копия статьи про «систему» Oberon/F, прообраз Инструментальный комплекс «BlackBox».
Оригинал: http://www.mactech.com/articles/mactech/Vol.13/13.03/OberonIntroduction/index.html
Обсудить: http://forum.oberoncore.ru/viewtopic.php?p=51745#p51745

Looking for a multi-platform, object oriented framework and extensible programming environment? Oberon/F might be the answer

Ever thought about taking a break from the «same old stuff»? Or are you a Pascal devotee watching the wholesale switch to C and C++? Do you want a development system that works with and for you instead of you working for it? Looking for an object oriented framework that is cross-platform? Take a look at the Oberon/F system from Oberon Microsystems, Inc. of Zürich Switzerland.

The computer language Oberon-2 was developed by Niklaus Wirth (Pascal, Modula-2) and his associates at the Eidgenössische Technische Hochschule (Swiss Federal Institute of Technology — abbreviated «ETH») in Switzerland. It was developed, first as the language Oberon, and later Oberon-2, together with an environment and operating system also called Oberon. Originally, this was the foundation of the Ceres ETH workstation. Oberon and its environment have since been ported to many platforms, including the MacOS, various PC implementations, and a variety of unix machines. There are commercial versions of the language and environment for many different computers.

The language Oberon-2 is a compiled, strongly typed, garbage collecting language with late-binding that is a descendant of Pascal and Modula-2. It is a simple yet powerful language that provides just the features necessary and no more. It can be used for structured modular programming as well as for object-oriented programming. Pascal and Modula-2 programmers can read most Oberon-2 programs without much trouble, and after a little acquaintance, are soon writing programs of their own. C/C++ programmers must readjust a bit but can soon be using Oberon/F to create their own components. A good book on object-oriented programming that uses and demonstrates Oberon-2 is Hanspeter Mössenböck: Object Oriented Programming in Oberon-2, Springer Verlag, 1993. ISBN 3-540-60062-0.

Oberon (and Oberon/F) is an object oriented language. The language was developed with the notion of extensibility of software, especially by the user. Extensibility allows a user to extend the software without having any original source. This is different from the typical object oriented approach of class libraries where source code often must be available to the user of the libraries for further inspection and reuse. In Oberon, new functionality can be added at any time without the original software author's help. New software is added to or embedded in the user's software to extend its original functionality. For example, a word processor can have a movie-playing module added by a different company at a later date without the word processor author having anything to do with it.

Oberon/F is an implementation of the Oberon-2 language (called Oberon/L by Oberon Microsystems in their implementation) consisting of a run-time and development environment and an object oriented framework (hence the /F). The «look and feel» of the system and software developed with it is that of the platform. Unlike other Oberon systems, Oberon/F does not impose its own user interface, and the familiar Mac or Windows interface is presented to the user. Oberon/F is available for the MacOS and for 32-bit Microsoft Windows (3.x w/Win32S, W95, NT). A UNIX/Motif version may be forthcoming. This review deals primarily with the MacOS version. The version reviewed is developer (commercial) version 1.2.

Oberon/F for Mac requires a MacOS compatible computer with a 68020 processor or higher or a PowerPC processor. It also requires an FPU or FPU emulator when running on non-FPU versions of the 68K family as well as on the PPC.[SoftwareFPU from John Neil works nicely. -ERR ]

Oberon/F on the Macintosh currently compiles 68K code only. Oberon Microsystems has announced that a PPC compiler should be available later this year. The lack of an available PPC compiler is unfortunate and I look forward to its arrival.

Oberon/F uses a cross-platform framework for MacOS and Windows built on the Oberon-2 language. Though it is possible to create large double-clickable applications with Oberon/F, the emphasis in Oberon/F is on components, not monolithic applications. Release 1.2 includes its own efficient proprietary component system on the Mac and includes full support for OLE on Windows. OpenDoc support on the Mac is promised, and should be available later this year. This means that you can program your components using Oberon/F and they will automatically work in OLE and OpenDoc. Oberon Microsystems has also released an Oberon compiler with Direct-to-COM support for «Safer OLE» on the Windows platform. A Direct-to-SOM Oberon compiler on the Mac may be in the works, but the exact status of that project is unclear. [By press time, we were not certain of the status of several of these pending projects, such as the PPC compiler, the SOM compiler, native OpenDoc, and UNIX implementation. -ERR ]

There are three general ways Oberon/F can be used on MacOS:

• Use the Oberon/F framework (exclusively) to produce cross-platform software (components).
• Use straight Oberon-2 language and program the MacOS similarly to the way one programs the Mac with Pascal or C using toolbox and manager calls.
• Combine the two approaches: use the framework and add new custom framework modules to take advantage of MacOS specific features that are not in the framework's built-in functionality, such as QuickDraw GX.

The Oberon/F framework is modeled on the Models, Views, Controllers (M-V-C) model from SmallTalk and Xerox PARC. To program in Oberon/F you design your software so that the data is represented by a set of objects referred to as models. This data is accessed through views which can represent a given model in different ways. Manipulating the data is done through a controller object. Different views can access the same model, and if the model changes, the views are notified to update their representations.

Abstract sets of layers isolate modules from each other and from the hardware. This makes it easier to program for extensibility and to support cross-platform components. The hardware interaction is restricted to low level objects. The basic Store object represents persistent data on a given medium. This Store object provides reading and writing functions for mapping data types like integers, characters, etc. into binary data for storage on a disk or in a file. Models, Views, and Controllers are extensions of Store objects and are the basic building blocks for writing components in Oberon/F. The following listing is an example of a simple program that will take the selected text in the current window and perform a ROT-13 upon it. This program is in the form of a command which is a parameterless procedure used to extend another program. This module can be added to any Oberon/F program that runs in the standard Oberon run-time environment and that uses the standard Oberon/F framework subsystem called Text (or an extension of this subsystem). [A ROT-13 jumbles and unjumbles text. It is used by Usenet groups to hide the text from casual observers. -ERR ]

The program imports only those modules it will use, such as the Text subsystem. Inside our Do procedure we declare a controller, tc, a text reader, tr, a writer, tw, and a model, buf. We also declare some helper variables to represent the beginning and ending locations of the selected text and to hold the current. The script is a special object that allows us to easily implement undo/redo functionality. We first set up our controller to point to the currently focused window. If it exists and has a selection then we get that selection and set our beginning and ending helper variables. We then instantiate a new writer for our model, buf, as well as a reader. Then we iterate over our selected text and do our ROT-13 operation. As we operate on each character, we save it to our model. After traversing the selection and building a new ROT-13 version in our local model, we copy it to our original text item and replace the original with the new version. The end result is that the original selection in our text window at command execution is now mixed up by a ROT-13 operation.

MactechRot13

(* This Module is a sample using the Oberon/F framework. It performs a ROT-13 on the current text selection. 
This module can be added to any program that uses the text subsystem. PROCEDURE Do is a parameterless 
procedure called a "command." This is a complete module and can be compiled by itself. *)
 
MODULE MactechRot13;
 
 IMPORT Models, TextModels, TextControllers, Domains;
 
 PROCEDURE Do*;
 
   VAR  tc: TextControllers.Controller; 
 beg, end: LONGINT;
 tr: TextModels.Reader; 
 ch: CHAR;
 buf: TextModels.Model; 
 tw: TextModels.Writer;    
 script: Domains.Operation;
 
 BEGIN
 tc := TextControllers.Focus();
 IF (tc # NIL) & tc.HasSelection() THEN
 tc.GetSelection(beg, end);
 buf := TextModels.Clone(tc.text); 
 tw :=buf.NewWriter(NIL);
 tr := tc.text.NewReader(NIL); 
 tr.SetPos(beg);
 tr.ReadChar(ch);
 WHILE (tr.Pos() <= end) & ~tr.eot DO
 IF ((ch >= "a") & (ch <= "m")) OR
   ((ch >= "A") & (ch <= "M")) THEN 
 ch := CHR(ORD(ch)+13);
 ELSIF ((ch >= "n") & (ch <= "z")) OR 
 ((ch >= "N") & (ch <= "Z")) THEN 
 ch := CHR(ORD(ch)-13)
 END;
 
 tw.WriteChar(ch);
 tr.ReadChar(ch)
 END;
 Models.BeginScript(tc.text, "Rot13", script);
 tc.text.Delete(beg, end); 
 tc.text.CopyFrom(beg, buf, 0, end - beg);
 Models.EndScript(tc.text, script)
 END
 END Do;
 
END MactechRot13.

The Oberon/F framework as shipped includes two subsystems that can be used and extended. These are the Text and the Forms subsystems. Oberon Microsystems, Inc. and third parties are releasing (or will release in the future) other subsystems including database access, high precision math, and others. For example, the Sql subsystem was recently released and is a full featured SQL access subsystem that comes with the dtF SQL database system.

The Text subsystem provides basic formatted text services, similar to TextEdit. It includes styled text and other basic word processor features. The Oberon/F development environment itself relies heavily on the Text subsystem. Most programs will probably rely on the Text subsystem or on developer extensions to this subsystem for their text processing.

The Forms subsystem allows easy development of user interface with dialogs and similar «form-like» objects. Each element in a given form is directly linked to an Oberon program variable. For example, a button may be linked to a boolean, a text field to a string, etc. When a user manipulates a button or types in the text field, the variable is automatically updated. Oberon/F also includes a visual interface designer to interactively build and test «forms.»

Figure 1. The forms subsystem links automatically to variables. There is a wide variety of graphical elements that can be placed in a form.

Oberon/F can be used for its Oberon-2 language implementation alone to program traditional MacOS applications. In this scenario, the software developer controls and is responsible for everything, just as when using C/C++ or Pascal. The standard event loop must be supported, all managers must be properly initialized, and all other housekeeping chores must be completed.

It is very easy to do traditional Mac programming with Oberon/F. If you already use Pascal, then switching to Oberon/F is a snap, as the languages are very similar and were invented by the same person. C programmers should also have little trouble once they shift into gear. Using the object oriented features of Oberon/F greatly expands the ability of the software developer to write robust software in a simple and maintainable way. With the garbage collection feature of the language, gone are many of the «Bus Errors» and memory leaks that so often afflict software written in other languages.

When using Mac specific data structures you must manage memory yourself, because Mac specific data structures used by the OS and the Toolbox lie outside the reach of the Oberon runtime system and cannot use garbage collection services. However, your application's own data structures can take full advantage of Oberon's features including garbage collection, and there are some techniques that allow you to take full advantage of garbage collection for your data structures that are referenced by the Mac. For example, using a window refCon is often used to keep an object pointer so that actions on windows can be done through a window's object passed back to the program. However, the Oberon system is not aware that your window record maintains a link to your object and so will garbage collect your window object when your application is not using it. The Oberon system is not usually in control of your window record, because it is a Mac data structure. Alternatively, you can keep a separate list of window objects, or you can have the window object keep a reference to itself. By referencing itself, the garbage collector knows that the object still has outstanding references and will not dispose of it until you set the self reference to nil.

Many standard MacOS traps and routines are all available to the Oberon programmer out of the box. This latest release of Oberon/F, V1.2, also gives us some automatic AppleScript support. The DoEvent Apple event allows one to execute any command (or parameterless procedure) externally through AppleScript or other AppleEvent aware application.

Each separate manager has its own MODULE defined for it. Some managers such as QuickDraw GX are not predefined. You must define them yourself if you wish to use them in Oberon. This is a shortcoming that I hope Oberon Microsystems, Inc. soon remedies.

The next listing shows a simple MacOS «Hello World» program in Oberon-2. This example does not use any Object Oriented features but shows how Mac toolbox routines are used in Oberon-2.

First, we declare a MODULE name. The MODULE name is in the subsystem MacTech and is called HelloWorld. (A subsystem is similar to a «manager» or «project» - a set of related code modules making up your software.) If you go looking about the various Oberon/F directories you would find a Code folder inside a MacTech folder and in the Code folder you would find the compiled version of the module with the name HelloWorld. The same goes for the Sym folder and the other Oberon folders for your subsystem. They contain the symbol files, source code, etc.

Next we IMPORT those modules we want to use in our module. This is similar to #include-ing in C/C++ or USE-ing in Pascal. Each specific Mac toolbox manager we want to use must be included. You can provide shortcut names for your imports so that when referencing data types and routines from these imported modules you do not have to provide the complete module name each time. I have done that in this sample program in most cases. I did not do it for the Font Manager or the Window Manager to demonstrate the effect in the code of not doing it. MODULE SYSTEM is imported because we use some MacOS specific Oberon routines as well. These routines, provided by Oberon Microsystems, Inc. help us interface to the Mac.

Our MODULE-level global variables are declared next. Then we declare our first procedure. This is a simple procedure that initializes all the Mac toolboxes for us (including ones we are not using in this simple program). Notice that each call we make or each datatype we use is prefaced with the name (or shortcut) of the module that contains it.

We then define the substance of our program, the PROCEDUREs MakeWindow and HelloWorld. MakeWindow creates a new window for us, displays it on the screen, and fills in the titlebar. HelloWorld writes the words «Hello World» in big letters in the middle of our window.

PROCEDURE Do is our «main» procedure and it calls the other routines in the proper order. Note that it is declared with an asterisk ‘*' after it. This means that it is to be exported from MODULE MacTechHelloWorld. It is also directly callable from the Oberon/F environment. You would merely type and select

MacTechHelloWorld.Do

and then choose Execute from the Dev menu and your program runs. Note also that the program body is blank. If this program were to be linked by the developer into a double clickable application, then the program body would call the Do procedure.

MODULE MacTechHelloWorld

(* This module demonstrates a simple "HelloWorld" program using the Mac toolbox calls with Oberon. This 
is a complete module by itself and can be compiled and run
as is. *)
MODULE MacTechHelloWorld; 
 
IMPORT
   SYSTEM,
 RM := MacResourceMgr,
 QD := MacQuickDraw, FS := MacFileMgr, 
 MacFontMgr, MacWindowMgr,
 MN := MacMenuMgr, TE := MacTextEdit, DL := MacDialogMgr, 
 MT := MacTypes,
 EV := MacEventMgr, ME := MacMemoryMgr, OS := MacOSUtils;
 
VAR
 
   gWindowRect : QD.Rect;
   gWindowRefCon : LONGINT;
   gWindow : MacWindowMgr.WindowPtr;
 
(* InitMac initializes the Mac ToolBox *)
PROCEDURE InitMac;
BEGIN
 QD.InitGraf(QD.globals.thePort);
    (* The QuickDraw Globals are Oberon Variables *)
 
 MacFontMgr.InitFonts;
 MacWindowMgr.InitWindows;
 MN.InitMenus;
 TE.TEInit;
 DL.InitDialogs(0);
 QD.InitCursor;
 
END InitMac;
 
 
(* Create a new window and display it *)
PROCEDURE MakeWindow;
 
VAR
 windowTitle : MT.Str255;
 temp : ARRAY 256 OF CHAR;
 behind : MacWindowMgr.WindowPtr; 
    (* behind flag in NewWindow *)
 
BEGIN
 
 temp := "MacTech Magazine";
 behind := SYSTEM.VAL(MacWindowMgr.WindowPtr, -1);
 MT.SetStr255(windowTitle, temp);
 QD.SetRect(gWindowRect, 50, 200, 300, 400);
 
 gWindow := MacWindowMgr.NewWindow(NIL, gWindowRect,           
 windowTitle, TRUE, MacWindowMgr.noGrowDocProc, 
 behind, TRUE, gWindowRefCon);
 
 MacWindowMgr.ShowWindow(gWindow);
 
END MakeWindow;
 
 
(* Draw our "HelloWorld" string in the window *)
PROCEDURE HelloWorld;
VAR
 oldPort : QD.GrafPtr;
 helloWorld : MT.Str255;
 temp : ARRAY 256 OF CHAR;
 
BEGIN
 
 temp := "Hello World";
 MT.SetStr255(helloWorld, temp);
 
 QD.GetPort(oldPort);
 QD.SetPort(gWindow);
 
 QD.TextSize(26);
 
 QD.MoveTo(25, 100);
 QD.DrawString(helloWorld);
 
 QD.SetPort(oldPort);
 
END HelloWorld;
 
(* Create our Do command. Can be run inside the Oberon environment. *)
PROCEDURE Do*;
BEGIN
 
 InitMac;
 
 MakeWindow;
 
 HelloWorld;
 
 REPEAT
   UNTIL EV.Button();
 
 MacWindowMgr.DisposeWindow(gWindow);
 
END Do;
 
(* Main program begin. If we are to compile and link this as a separate application then this section should 
make a single call to Do; *)
BEGIN
 
END MacTechHelloWorld.

The Oberon/F system supports the Code Fragment Manager (CFM) for external routines. This means that you can use any language that supports CFM to write routines and then use those routines in your Oberon programs. This allows you to take advantage of third party and Apple libraries as well as your own code. Even though I have not tried it, it should allow you to interface with SOM routines if you know the SOM names for your routines and how SOM works. On a PowerPC MacOS computer, CFM-access allows you to directly interface with PPC code, and the runtime system will make all the appropriate UniversalProcPtrs for you and make it all work. On PPC machines this is an easy way to interface with those Mac managers that are not predefined for you. (68K machines with CFM-68K can access CFM-code as well.) To use the CFM libraries, you define an Oberon Module that contains the routines to link. This module is then imported into your Oberon code and used regularly. See the following listing for an example.

MODULE BeepUtil

 MODULE BeepUtil ["InterfaceLib"];
 
 PROCEDURE SysBeep* (duration:INTEGER);
 END SysBeep;
 
 END BeepUtil.

No code is generated when this is compiled but your Oberon MODULEs are free to call any of these routines and the runtime system will search for the appropriate code fragment, load it and run the routine desired. Oberon/F and Mac Specific Extensions

One powerful way of using Oberon/F is to use the component framework and extend it for your own Mac-specific needs. This allows your modules that do not call Mac specific code to work correctly cross-platform. Only those modules that actually call Mac specific code need separate Mac and Windows implementations. This allows you to use API's like QuickDraw GX on Macs and an equivalent package on Windows and still have the substance of your application be cross-platform.

The Oberon/F development environment is a specialized subsystem running in the standard Oberon/F run-time environment. The development environment includes a text editor (using the Text subsystem), compiler, linker, visual designer for forms and dialogs, a «heap spy», and some shortcut commands that can create skeleton programs for you. The development environment is fully extensible. You can change any of the menus and add any of your own code to it as well. A source code analyzer and a statistical profiler tool for performance analysis are available separately from Oberon Microsystems for a modest fee.

Figure 2. This composite illustration of a number of the development environment menus gives a flavor of the rich environment.

With garbage collection, many typical program bugs are eliminated automatically, with no more memory leaks or «bus errors» (except when interfacing directly to the system). However, errors of logic and other bugs will still afflict an Oberon program. Typical Oberon development is to design the project, code the modules, and use assertions to test each routine. If, when testing a running program, an error occurs, a stack crawl trap window appears. This window displays the error trap that occurred and a stack crawl. You can examine the variables of each routine in the stack crawl as well as go directly to the source code of any routine in the stack crawl. (See Figure 1.) As the Oberon/F help files say, the debugging facilities are a cross between a «post-mortem» debugger and «run-time» debugger. The debugging facilities are integrated into the development environment and when a program has an error trap, the rest of the system continues to run. The system degrades gracefully whenever possible. The Oberon/F language, environment, and debugging facilities lend themselves to quick debugging of problems with careful use of assertions and the error trapping facilities.

Figure 3. Debugger/stack crawl window.

The complete environment comes on two compressed floppies. No CD is needed, nor do you need large amounts of hard disk space. The complete system includes the compiler and development/runtime environment, Text and Forms subsystems, help files, on-line documentation for the Oberon-2 language and the Oberon/F package, and examples. On my system, this took up slightly more than 7.1 MB (5,213,993 bytes). The compiler is very fast and the interactive environment makes rapid development fast and easy.

Oberon/F makes an excellent development system for those wanting to develop quality component software on the Macintosh (and Windows). The language allows for object-oriented, modular, and structured programming techniques. It is a clean and simple language, and is garbage collected for safety. It supports late-binding to allow for run-time extensibility of software. The Oberon/F framework is completely cross-platform on Macintosh and 32-bit Windows and can also be extended for platform specific use. Oberon and Oberon/F are being used commercially, especially in Europe, by those companies who want fast and accurate development of software.

Oberon Microsystems, Inc. is in Zürich Switzerland. Their distributor in the USA is dtF Americas. Their address is:

dtF Americas, Inc.

19672 Stevens Creek Blvd., Suite 128

Cupertino, CA 95014 USA

voice 800-dtF-1790

fax 510-828-8755

email: dtF@interramp.com

The address and contact info for Oberon Microsystems, Inc. in Switzerland is:

Oberon Microsystems, Inc.

Technopark

Technoparkstrasse 1

CH-8005 Zürich Switzerland

fax +41 1 445 1752

  email: oberon@oberon.ch

  WWW: http://www.oberon.ch/Customers/omi/

To subscribe to their announcements mailing-list send the following: «subscribe to Oberon/F announcements» to oberon@oberon.ch.

The price from Oberon Microsystems, Inc. is 450 CHF (Swiss Francs) for the Macintosh or Windows developers versions. An educational version is available at no cost. The major difference between the educational and commercial developer versions is the absence of an external linker in the educational version (and no OLE support in the Windows educational version). This means that all code written with the educational version must run in the Oberon/F runtime environment and stand alone applications cannot be created. The educational version also puts a message in every window and document stating that it is in the educational version, and a license for commercial distribution of software is not granted. The non-commercial educational use version can be downloaded from the internet from the WWW site. Contact dtF Americas directly for information on their US offering of Oberon/F.