[Oberon] Protocols (interfaces) in Oberon-2

[Stewart Greenhill]

I'm not sure if I caught all of this interesting discussion, but here are a
couple of points.

Interfaces are of course an important mechanism for component software
frameworks, such as Microsoft's COM (Component Object Model). COM defines a
language-independent binary standard for communication between objects,
whether they are in the same process, in different processes on the same
machine, or on different machines.

https://docs.microsoft.com/en-us/windows/win32/com/com-objects-and-interfaces

During the 1990s, Oberon Microsystems implemented an extension of the
Component Pascal compiler in Blackbox which was called "Direct TO COM" (or
"DTC"). This allowed COM components to be written in Component Pascal, and
for such components to interact with objects written in any other language.

https://web.archive.org/web/20040618025116/http://www.oberon.ch/prod/DTC/index.html

I can't remember all the details, but one of the important technical issues
is that COM interfaces (and therefore the generated Oberon objects) use C++
VTBL object representation. That is, the first element of every object is a
pointer to a table of its virtual methods, which is different to the usual
layout for Oberon-2 records.

COM is based on a fairly simple but powerful idea: Every object must
implement the interface "IUnknown", and every interface must extend
IUnknown. The method IUnknown:QueryInterface allows the client to retrieve
other interfaces of the object, which in COM are named using GUIDs
("globally unique identifier). This mechanism allows an object to implement
one or more of its own interfaces, or indeed for it to delegate its own
interfaces to other objects (eg. via aggregation)

PROCEDURE (this: IUnknown) QueryInterface (IN [iid] iid: GUID; OUT [new]
int: IUnknown): RESULT;


To implement a single interface, you define an object that extends the
interface type. To implement multiple interfaces, you would need to define
a separate object for each additional interface, which would hold a pointer
to the main object and forward any method calls from the interface object
to the main object. This could involve some work, but would be fairly
simple and could potentially be automated.

A slightly different implementation is described in "Fine-grained
integration of Oberon into Windows using pluggable objects" by Emil Zeller.
This includes a quite detailed description of how he integrated Oberon-2
objects into Microsoft's OLE2 compound document model. This includes
interfaces for object persistence, display, and interaction. There is also
an interface "IDispatch" which allows properties and methods of objects to
be enumerated at run-time, so that components can be integrated into
scripting environments or visual editors.

https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/72691/eth-26257-02.pdf

I'm not sure much of this is directly useful, but its definitely worth
understanding what COM is and how it works. The underlying ideas are fairly
simple, and could easily be emulated in a small-scale project.

Cheers,
  Stewart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20201028/0547db09/attachment.html>