Phoenix Object Basic – Wikipedia

Phoenix Object Basic
Envelop - Entwicklungsumgebung
Basisdaten
Entwickler	Cimlinc Inc. Janus Software
Erscheinungsjahr	1995[1]
Aktuelle Version	Windows 1.4 Linux 1.5 Beta 6
Betriebssystem	Windows und Linux
Programmier­sprache	C++
Kategorie	Integrierte Entwicklungsumgebung (IDE)
Lizenz	proprietär
deutschsprachig	nein
www.envelop.com (offline) www.janus-software.com

Phoenix Object Basic (ehemals Envelop) ist eine integrierte Entwicklungsumgebung, die im Jahr 1995 vom US-amerikanischen Unternehmen Cimlinc entwickelt wurde.^[2][3] Nach dem Ende der Entwicklung durch Cimlinc wurde das Projekt vom niederländischen Unternehmen Janus Software übernommen und in Phoenix Object Basic umbenannt. Dort wurde die Entwicklungsumgebung für das Betriebssystem Linux portiert.

Die Entwicklungsumgebung ermöglicht Rapid Application Development (RAD) in einer eigenen objektorientierten Programmiersprache, die sich sehr stark an Visual Basic 3 orientiert. Die Gestaltung der grafischen Benutzeroberfläche von Envelop sowie die dort bereitgestellten Werkzeuge sind ebenfalls an Visual Basic angelehnt.

Die letzte Version (1.4) für Windows erschien im Jahr 1996.^[2] Die letzte Version (1.5 beta 6) für Linux erschien im Jahr 2004. Die Website von Envelop existiert nicht mehr und die Software wird nicht mehr angeboten.

Phoenix Object Basic ist eine imperative, objektorientierte Programmiersprache.^[4][5]

Phoenix Object Basic ist eine objektorientierte Programmiersprache. Im Gegensatz zu den meisten objektorientierten Programmiersprachen, findet allerdings keine explizite Aufteilung in Klassen und Objekte statt. Allgemein stellen Objekte eine Instanz einer Klasse dar. Eine Klasse ist eine Menge aller Objekte mit gleichen Attributen und Operationen.^[6]

In Phoenix Object Basic können bestehende Objekte kopiert und abstrahiert werden. Die Abstraktion eines Objekts bildet das Prinzip der Vererbung nach. Mehrfachvererbung ist mit Envelop nicht möglich. Zudem existieren in Envelop auch keine Sichtbarkeiten für Attribute und Methoden. Objekte können entweder zur Entwurfszeit über die Entwicklungsumgebung abstrahiert werden^[7][8] oder dynamisch während der Laufzeit. Das globale Objekt ObjectTools stellt eine Reihe von Methoden zur Verfügung, mit der Objekte dynamisch abstrahiert, verwaltet und untersucht werden können.^[9] Es handelt sich dabei um grundlegende Funktionen von Reflexion.

Über das globale Objekt SystemTools kann zur Laufzeit mit dem Betriebssystem interagiert werden.^[10]

Phoenix Object Basic stellt folgende Datentypen bereit:

Einschränkungen der Datentypen:

• Es existieren für Ganzzahlen weder 1 Byte noch 8 Byte (64-Bit) große Datentypen.
• Zudem sind numerische Datentypen in Envelop stets mit einem Vorzeichen behaftet.
• Ähnlich wie in Visual Basic werden boolesche Ausdrücke als vorzeichenbehaftete 2 Byte Ganzzahl gespeichert, bei dem der Wert −1 True und der Wert 0 False entspricht.^[17] Im Gegensatz zu Visual Basic wird allerdings auf einen eigenen Datentyp Boolean verzichtet, sondern auf den Datentyp Integer zurückgegriffen.^[11]
• Es existiert im Gegensatz zu Visual Basic kein Datentyp für Datums- und Zeitangaben. Meistens werden diese Angaben als Zeichenfolge zurückgegeben, wobei es Unterschiede im Format gibt. An manchen Stellen werden numerische Angaben zur Repräsentation verwendet.

In Phoenix Object Basic wird (wie in den meisten Dialekten der Programmiersprache BASIC) zwischen Funktionen (Function) und Subroutinen (Sub) unterschieden. Funktionen sind Methoden, welche einen Wert zurückgeben, während Subroutinen keinen Wert zurückgeben können.

Parameter können als Wert oder als Referenz übergeben werden. Soll ein Parameter als Wert übergeben werden, muss das Schlüsselwort ByVal vor dessen Deklaration geschrieben werden. Fehlt dieses Schlüsselwort, so wird der Parameter implizit als Referenz übergeben.^[18] Anders, als in Visual Basic, gibt es hier kein explizites Schlüsselwort ByRef.

In Phoenix Object Basic können auch Methoden aus externen Dynamic Link Libraries (DLL) aufgerufen werden.^[5][19] Die Syntax zur Deklaration externer Methoden ist dabei ähnlich zu der von Visual Basic.^[20] Obwohl die Entwicklung von Envelop 1996 (also zu Zeiten von Windows 95) eingestellt wurde, können auf diese Art und Weise auch Funktionen aus neueren Windows-Versionen verwendet werden. Da Envelop nur 32 Bit Anwendungen erzeugen kann^[21], können jedoch nur externe Funktionen aus 32 Bit DLLs genutzt werden.^[22] Plattformabhängige Funktionen können allerdings nicht aus anderen Betriebssystemen heraus aufgerufen werden.

Declare Function FileEncryptionStatus Lib "Advapi32" Alias "FileEncryptionStatusA" (ByVal lpFileName As String, lpStatus As Long) As Integer 

Das Beispiel zeigt die Deklaration der externen Funktion FileEncryptionStatus, mit der man ab Windows 2000 ermitteln kann, ob eine angegebene Datei verschlüsselt ist oder nicht.^[23] Diese Funktion steht erst seit Windows 2000 zur Verfügung. Der Dateiname wird über den Parameter lpFileName als Wert übergeben. Der Status wird als Referenz über den Parameter lpStatus zurückgegeben. Die Funktion selbst gibt einen booleschen Wert zurück, der angibt, ob der Funktionsaufruf selbst erfolgreich war oder nicht. Da es in Envelop keinen booleschen Datentyp gibt (siehe oben), wird der Rückgabewert ersatzweise als 2 Byte Integer deklariert.

Im Gegensatz zu den meisten BASIC Programmiersprachen der damaligen Zeit, werden in Envelop keine numerischen Fehlercodes und Sprunganweisungen (Goto) zur Verarbeitung von Fehlern verwendet, sondern das Prinzip der strukturierten Ausnahmebehandlung (Try-Catch-Prinzip).^[24]

Sub btnDiv_Click()   Dim m as New MessageBox   m.SetIconStop   Try     txtResult.Text = txtNum1.Text / txtNum2.Text   Catch ConvertFailed     m.Message("Fehler", "Bitte geben Sie zwei Zahlen ein!")   Catch FPException     m.Message("Fehler", "Division durch 0 ist nicht erlaubt!")   Catch     m.Message("Fehler", "Es ist ein unbekannter Fehler aufgetreten!")   End Try End Sub 

Das Beispiel zeigt einen Ausschnitt aus einem simplen Taschenrechner. Wenn der Benutzer die Schaltfläche „Dividieren“ (btnDiv) anklickt, wird versucht, den Wert des ersten Eingabefelds (txtNum1 durch den Wert des zweiten Eingabefelds txtNum2) zu teilen und das Ergebnis in das Textfeld txtResult zu schreiben. Sollte dies nicht gelingen, wird eine Ausnahme ausgelöst. Im Fehlerfall werden zuerst Konvertierungsfehler (ConvertFailed) abgefangen, danach numerische Fehler (FPException) und abschließend alle anderen Fehler (z. B. bei zu wenig Speicherplatz). In jedem Fall wird dem Benutzer eine entsprechende Fehlermeldung in einem Dialogfenster angezeigt.

Phoenix Object Basic stellt einen grafischen Editor zur Erstellung von grafischen Benutzeroberflächen bereit.^[4][21] Dieser ist nahezu identisch zum Formulareditor von Visual Basic. Diese Formularentwürfe werden in einer Objekt-Datei (*.ebo) gespeichert.

Für alle Elemente zur Gestaltung von grafischen Benutzeroberflächen, die über ein sogenanntes Handle verfügen, existiert das Basisobjekt Window. Davon leiten sich Formulare (Form) und Steuerelemente (Control) ab.^[25]

Die nachfolgenden Steuerelemente existieren sowohl für die Zielplattform Windows, als auch für Derivate des Betriebssystems Linux.

Darüber hinaus kann für jedes Formular eine Menüleiste mit Hilfe eines visuellen Editors angelegt und bearbeitet werden.

Neben den plattformunabhängigen Standardelementen, stehen unter Microsoft Windows noch einige zusätzliche Komponenten bereit:

Darüber hinaus können unter Microsoft Windows auch noch 32 Bit ActiveX-Komponenten von Microsoft oder Drittanbietern eingebunden werden.^[43]

Ebenso besteht dort die Möglichkeit, OLE-Objekte einzubinden.^[44] Dabei handelt es sich beispielsweise um Verbunddokumente aus der Microsoft-Office-Familie (Word-Dokumente, PowerPoint-Folien, Excel-Tabellen und -Diagramme), digitale Medien, CAD-Zeichnungen oder beliebige andere Dateien. Unter Linux wird dieses Konzept nicht unterstützt.

Im Gegensatz zu Visual Basic gab es in der finalen Version von Envelop bereits im Jahr 1996 die Möglichkeit, benutzerdefinierte Steuerelemente zu erstellen. Diese werden in Envelop als Hyper-Control bezeichnet.^[45] Ein benutzerdefiniertes Steuerelement ist eine Gruppierung mehrerer (primitiver) Steuerelemente zu einem neuen komplexen Steuerelement.^[21] Diese kann man innerhalb eines Projekts oder auch in mehreren Projekten an mehreren Stellen wiederverwenden. Derartige Steuerelemente können auch eigene Eigenschaften, Methoden (z. B. Konsistenzprüfungen) und Ereignisse besitzen und an Datenquellen gebunden werden. Beispiele dafür sind unter anderem Eingabemasken für Postadressen, Produktdaten oder Daten in digitalen Patientenakten. Dieses Konzept hat sich in vielen Programmiersprachen durchgesetzt und findet auch heute noch Verwendung. Zur damaligen Zeit war die Bereitstellung derartiger Möglichkeiten zumindest für BASIC-Programmiersprachen nicht selbstverständlich und daher ein deutlicher Mehrwert dieser Programmiersprache.

Ähnlich wie in Visual Basic und den meisten modernen RAD-Entwicklungsumgebungen können Steuerelemente an eine Datenquelle gebunden werden.^[4][5] Dadurch können klassische formularbasierte Anwendungen zur Datenerfassung und -verarbeitung einfach und schnell entwickelt werden. Komplexe Eingabemasken können mit sogenannten Hyper Controls realisiert werden.

Formularentwürfe, Steuerelemente und Code-Dateien werden in Objektdateien (*.ebo) gespeichert. Diese sind intern nach dem Compound File Binary Format (CFBF) aufgebaut und können in beliebig vielen Projekten wiederverwendet werden. Allerdings lassen sich daraus keine DLL oder OCX Dateien generieren.

Eine Besonderheit von Envelop ist die Tatsache, dass die Entwicklungsumgebung teilweise selbst in Envelop-Basic programmiert ist und durch Entwickler angepasst und erweitert werden kann.^[5] Auf diese Art und Weise kann man beispielsweise die Benutzeroberfläche in eine andere Sprache übersetzen, Makros entwickeln (Automatisierung) oder eigene Assistenten programmieren. Die Weiterentwicklung der Programmiersprache selbst bzw. des Compilers (Bootstrapping) ist allerdings nicht möglich.

Der Quellcode für die zentralen Elemente der Sprachverarbeitung ist nicht öffentlich verfügbar, da hier urheberrechtlich geschützte Elemente eingesetzt werden.

Envelop generiert ausschließlich 32 Bit Anwendungen für Windows. Bei den kompilierten Apps handelt es sich jedoch nicht um Stand-Alone-Anwendungen. Bei der Verteilung der Apps müssen einige Laufzeitkomponenten mit ausgeliefert werden. Um dies zu erleichtern, wird neben der IDE auch ein rudimentäres Programm zur Erstellung von Installationsprogrammen für Envelop Anwendungen mitgeliefert.

Envelop und die damit erstellten Programme sind grundsätzlich auch noch unter der 32-Bit-Version von Windows 10 lauffähig, wenn NTVDM installiert wurde. Unter der 64-Bit-Version von Windows steht dieser Dienst nicht bereit, weshalb Envelop Programme dort generell nicht ausgeführt werden können. Die Entwicklungsumgebung und die damit erstellten Programme dürfen allerdings keine visuellen Stile nutzen, da sie sonst nicht lauffähig sind und abstürzen. Visuelle Stile werden entweder über eine Manifest-Datei oder eine Manifest-Ressource aktiviert. Andere Funktionen, die durch Manifest-Dateien aktiviert werden können, werden durchaus unterstützt. Dazu zählen unter anderem:^[46]

• Zugriff auf Funktionen, die Administratorrechte erfordern.
• Skalierung der Benutzeroberfläche auf hochauflösenden Bildschirmen.
• Unterstützung von langen Dateipfaden.
• Nutzung der Druckertreiberisolation.

Bei Linux Betriebssystemen müssen einige alte Pakete installiert werden, um Envelop und die damit erstellten Programme lauffähig zu machen.

Seit die Entwicklung im Jahr 2004 eingestellt wurde, hat die Entwicklungsumgebung bzw. Programmiersprache keine nennenswerte Verbreitung gefunden.

Die Entwicklung von Envelop für Windows wurde bereits 1996 eingestellt. Die letzte Version für Linux erschien im Oktober 2004. Seitdem haben sich einige BASIC-Entwicklungsumgebungen und -Frameworks entwickelt, die den Anforderungen von modernen Endgeräten und Betriebssystemen, besser gerecht werden. Als Envelop auf den Markt kam, gab es nur wenige BASIC-Entwicklungsumgebungen mit einem komfortablen WYSIWYG-Editor für die Gestaltung grafischer Benutzeroberflächen. Microsoft Visual Basic war damals der bekannteste Vertreter dieser Gruppe. Im Gegensatz zu den anderen BASIC-Entwicklungsumgebungen war Envelop stets kostenlos.

Phoenix Object Basic bildet die Entwicklungsumgebung Visual Basic 3 und 4 nahezu vollständig nach. Allerdings ist Visual Basic nicht für unter Linux nutzbar. Diese Lücke wird durch das Linux-Pendant Phoenix Object Basic abgedeckt.

Seit 1999 existiert mit der Entwicklungsumgebung Gambas eine exklusive Alternative für Varianten des Betriebssystems Linux. Über das Windows-Subsystem für Linux ist es allerdings auch möglich, Gambas unter dem Betriebssystem Windows auszuführen. Diese Programmiersprache wird immer noch gepflegt und aktiv weiterentwickelt. Die aktuelle Version 3.16.3 erschien am 15. September 2021.^[47]

Eine weitere kostenpflichtige Entwicklungsumgebung aus der damaligen Zeit stellt REALbasic dar. Diese Software wird bis heute unter dem Namen XOJO gepflegt und weiterentwickelt.

Für sehr alte Betriebssysteme (z. B. Windows 95) kommen die nachfolgenden Alternativen nicht in Frage, da diese nur unter relativ modernen Betriebssystemen lauffähig sind. Folgende Entwicklungsumgebungen erlauben die Entwicklung von plattformübergreifenden Apps für Windows, Linux und macOS, wobei die ersten beiden auch noch die mobilen Plattformen Android und iOS abdecken.

• B4X
• Xamarin
• KBasic bzw. Basic For Qt

• Homepage (Memento vom 4. November 1996 im Internet Archive)
• Janus Software: Phoenix 1.4 for Windows (a.k.a. „Envelop“) (Memento vom 13. August 2007 im Internet Archive; EXE; 7,4 MB)
• Janus Software: Phoenix 1.5 for Linux Beta 6 (Memento vom 13. August 2007 im Internet Archive; RPM; 4,0 MB)
• Janus Software: Phoenix 1.5 for Linux Beta 6 (Documentation) (Memento vom 13. August 2007 im Internet Archive; RPM; 1,7 MB)