VisualLisp hat mit seiner Einführung in AutoCAD (zunächst als zusätzlich zu ladender Aufsatz in R14, ab A2000 dann genauso wie die VBA-Schnittstelle als integraler Bestandteil von AutoCAD) einige neue Dinge in den Alltag der AutoLisp-Programmierer gebracht:

• Zunächst einmal steht nun mit der ActiveX-Schnittstelle nach (command...) und (entmake ...) bzw. (entmod ...) eine weitere Möglichkeit zur Erzeugung und Modifikation von Geometrie zur Verfügung. Aber es stehen auch jenseits der Geometriedatenbank neue Möglichkeiten zur Verfügung, Einfluss auf AutoCAD zu nehmen, z.B. was die aktuellen Einstellungen beim Arbeiten betrifft. Hier gibt es jetzt Eingriffsmöglichkeiten, die vorher nicht vorhanden waren.
  
  
• Zur ActiveX-Schnittstelle gehören auch die Reaktoren. Diese stellen das dar, was man in anderen Sprachen schlicht als 'Event-Handler' bezeichnet, in VBA gehören sie einfach dazu und sind eigentlich nichts ungewöhnliches. Sie ermöglichen es, bestimmte Lisp-Funktionen nicht selbst aus einem Programmkontext heraus aufzurufen, sondern in Abhängigkeit von Ereignissen aufrufen zu lassen. Sie heissen also Reaktoren, weil sie auf diese Ereignisse reagieren.
  
  
• Ferner wurden auch neue Funktionen mit VisualLisp eingeführt, die mit ActiveX überhaupt nichts zu tun haben. So gibt es jetzt die Möglichkeit, Dateien zu löschen, Symbole in Zeichenketten umzuwandeln, einige neue Methoden der Listenbearbeitung sind hinzugekommen usw. Auf diese Funktionen werde ich übrigens im Rahmen dieses Tutorials nicht eingehen, sie werden im Einsteiger-Teil behandelt werden!
  
  
• Ebenfalls neu ist die VisualLisp-Entwicklungsumgebung, bisher war so etwas in AutoCAD überhaupt nicht vorhanden. VisualLisp stellt einen Editor mit Syntax-Highlighting und Debugger zur Verfügung. Editoren mit Syntaxprüfung und 'pretty printing' gab es schon vorher, ein integrierter Debugger ist allerdings wirklich neu.
  
  
• Über die IDE kommt eine weitere neue Möglichkeit ins Spiel: Das 'kompilieren' der Lisp-Programme. Damit entfernt sich AutoLisp von der reinen Interpreter-Sprache und bewegt sich ein Stück in Richtung Compilersprache, es wird die bisher nicht vorhandene Trennung zwischen Programm und Daten eingeführt. AutoDESK verspricht in diesem Zusammenhang verkürzte Programm-Laufzeiten sowie Schutz vor Software-Piraterie.

Um den Einstieg in die Materie zu erleichtern, hier noch eine Übersicht - die Namen der in VisualLisp neuen Funktionen teilen sich wie folgt ein:

• (vlax-...) heissen die ActiveX-Funktionen, die nichts mit den Reaktoren zu tun haben
  
  
• (vlr-...) heissen die Reaktor-Funktionen
  
  
• (vla-...) heisst eine weitere grosse Gruppe von ActiveX-Funktionen. Hierbei handelt es sich nicht um direkt im Lisp-Interpreter implementierte Funktionen, sondern um (durchaus verzeichtbare) Makros für Aufrufe von (vlax-...)-Funktionen. Eine Online-Dokumentation gibt es in AutoCAD nicht!
  
  
• Und schliesslich bleibt noch die Gruppe der (vl-...)-Funktionen sowie einiger Funktionen, bei denen der Präfix (vl-...) weggelassen wurde. Es handelt sich um die neuen Lisp-Funktionen, die mit ActiveX nichts zu tun haben.

VisualLisp ist (leider) alles andere als das Ergebnis einer konsequenten Pflege der AutoLisp-Schnittstelle durch AutoDESK, denn es handelt sich um eine zugekaufte Applikation: Ursprünglich hiess das Paket 'VitalLisp' und wurde in Russland entwickelt. In den ersten (gebührenpflichtigen) Versionen von VisualLisp war noch der Rote Stern, das Logo von 'Vital Lisp', auf einigen Buttons zu sehen.

AutoDESK kaufte also (überraschend? - nein, AutoDESK kauft ja alles Mögliche) VitalLisp, machte 'VisualLisp' daraus und integrierte das Paket dann vollständig ab der 2000er Version. Der Namensbestandteil 'Visual' ist zwar derzeit ungemein modern, aber hier völlig irreführend: Ein 'Zusammenschieben' von Programmen mit der Maus, ohne eine Codezeile zu schreiben, ist nicht möglich - im Gegenteil: 'Visual' ist hier absolut nichts.

Was bringt dem Anwender dieses neue Paket? Fangen wir anders herum an: die neuen (vl-...)-Funktionen sind eine Bereicherung, da sie Möglichkeiten schaffen, die bisher nicht gegeben waren. Aber auch die ActiveX-Schnittstelle ermöglicht Neues: Arbeiten über mehrere Zeichnungen hinweg, Eingriffe in die Konfiguration von AutoCAD, Kommunikation mit anderen Programmen usw.

Die Reaktoren versprechen viel, aber es ist mehr als fraglich, ob sie auch halten, was sie versprechen: Schon in den Online-Hilfen wird auf Vieles verwiesen, was man besser innerhalb der (bei Eintritt eines entspr. Ereignisses automatisch aufgerufenen) Callback-Funktionen lieber bleiben lassen sollte. In der Praxis verlängert sich dieser Sünden-Katalog noch erheblich - aber es gibt kaum noch gültige Kriterien, nach denen man vorgehen kann. Man kann eigentlich nur noch ausprobieren, was läuft und was abstürzt - es wird zur Glückssache.

Die Reaktion der Anwender ist breit gestreut: Manche stürzen sich begeistert auf all die neuen Möglichkeiten, einige ziehen nach einiger Zeit eine Grenze und nutzen zwar die ActiveX-Funktionen, aber nicht die Reaktoren, andere lehnen alles, was mit den Buchstaben 'vl' anfängt, grundsätzlich ab. Ein Umstieg auf VisualBasic bringt hier aber auch keine Abhilfe: Da beide Sprachen auf die selben internen Mechanismen zurückgreifen, klagen die Basic-Kollegen über die gleichen Maroditäten.

Ich werde die Dinge offenhalten: In diesem Tutorial werde ich Möglichkeiten der ActiveX-Schnittstelle aufzeigen und auch auf die Reaktoren eingehen. Da die Kapitel noch nicht geschrieben sind, kann ich auch noch nicht sagen, was mein Fazit irgendwann sein wird. Bisher haben meine Erfahrungen ergeben, dass Programme mit Verwendung von Reaktoren laufen können oder auch nicht;-)))

Ich möchte an dieser Stelle einen Newsgroup-Beitrag zitieren, der von Tony Tanzillo (den man sicherlich als den 'Vordenker' aller AutoLisp-Programmierer bezeichnen kann) am 12.7.2002 in 'autodesk.autocad.customization' gepostet wurde. Auslöser war ein Beitrag, in dem wohl ein 'Bytecode-Decompiler' veröffentlicht wurde - dieser Beitrag selbst wurde allerdings von der 'AutoDesk-Aufsicht' sofort wieder gelöscht. Zunächst Tonys Beitrag im Original, anschliessend meine deutsche Übersetzung:

"I really don't care what anyone from Autodesk tells you, because the simple fact is that no bytecode based programming language is reasonably safe.

It has nothing to do with whether it is Visual LISP, Java, or MSIL, the simple fact is that bytecodes are bytecodes, and from now to the end of time, bytecodes can be decompiled to editable source code.

'Decompiled' does not mean reproducing the exact same original source code, but it does mean producing source that has the exact same structure, and which can be recompiled back into the same bytecodes. The primary difference between the original and reconstituted source code produced by a decompiler/disassembler, is that the latter uses different software-generated symbols for all variables and function names.

That means, that while the symbols you use for variables and functions cannot be restored, the basic source code (using symbols generated by the decompiler) can be reconstituted, and when compiled again, runs exactly the same as the original source.

Let's not forget that the whole point to Visual LISP, was to act as countermeasure to the threat from the AutoLISP-compatible IntelliCAD. IOW, the purpose of purchasing Vital LISP and distributing it with AutoCAD was to "pollute" the existing AutoLISP standard, and thereby provide you with the means to create LISP based applications that would not run on IntelliCAD.

It had nothing to do with giving you more API power, or a more "secure" way to deploy your applications, especially considering how many Visual LISP programmers have succeeded in using Visual LISP's highly flawed reactor implementation to do little more than crash AutoCAD or corrupt drawing files."

Die Übersetzung:

"Es ist mir egal, was irgendjemand von Autodesk erzählt, denn es ist einfach so, dass keine auf Bytecode aufgebaute Programmiersprache wirklich sicher ist.

Es spielt keine Rolle, ob es um Visual Lisp, Java oder MSIL geht. Es geht einzig und allein darum, dass es sich um Bytecode handelt - und von jetzt an bis in alle Ewigkeit wird es immer möglich sein, Bytecode in editierfähigen Quellcode zu dekompilieren.

'Dekompiliert' heisst nicht, dass der genaue Inhalt der Quelldateien wiederhergestellt wird, sondern, dass Quellcode erzeugt wird, der genau die selben Strukturen hat wie das Original und der erneut zum exakt gleichen Bytecode zurückkompiliert werden kann. Der wesentliche Unterschied zwischen dem Original und dem durch einen Decompiler/Disassembler gewonnenen Quellcode ist der, dass letzterer Symbole für die Variablen- und Funktionsnamen verwendet, die durch die Software erzeugt werden.

Das bedeutet, dass zwar die Bezeichner für Variablen- und Funktionsnamen nicht wieder hergestellt werden können, stattdessen aber ein Quellcode mit den Software-generierten Bezeichnern erzeugt wird, der - wieder kompiliert - sich genauso verhält wie der Original-Code.

Wir sollten einfach den Punkt nicht vergessen, dass es bei Visual LISP darum ging, als Gegenmaßnahme zur Bedrohung durch das AutoLSIP-kompatible IntelliCAD zu dienen. Mit anderen Worten: Ziel beim Kauf von Vital LISP und seinem Vertrieb zusammen mit AutoCAD war es, den bestehenden AutoLISP-Standard zu "verunreinigen" und so die Möglichkeit zu schaffen, auf LISP basierende Applikationen zu erstellen, die unter IntelliCAD nicht mehr lauffähig sind.

Es hatte nichts damit zu tun, dem Anwender mehr API-Power zu geben, oder einen "sichereren" Weg anzubieten, die eigenen Anwendungen einzusetzen. Vor allem wenn man bedenkt, wieviele Visual LISP-Programmierer erfolgreich darin waren, Visual LISP mit seiner hochgradig fehlerbehafteten Implementation der Reaktoren zu kaum mehr einzusetzen, als AutoCAD abstürzen zu lassen oder die Zeichnungsdateien zu beschädigen."

Das sind also deutliche Worte (Tonys Worte sind immer deutlich), die jeder, der a) glaubt, kompilierte Lisp-Programme seien sicher und/oder b) sich mit den Reaktoren befassen möchte, erst einmal zur Kenntnis nehmen sollte. Und ob ein Warten auf bessere Zeiten sich lohnt, möchte ich einmal dahingestellt sein lassen.

An anderer Stelle habe ich die 'Pflege' der Proteus/DCL-Schnittstelle beklagt: Seit der Einführung vor vielen, vielen Jahren hat sich dort absolut nichts mehr getan, obwohl inzwischen Dialoge einfach anders aussehen und der Anwender heutzutage andere Erwartungen an Funktionalität, Aussehen und Programmierung von Dialogen hat. Wird da auch wieder das zugekauft, wo derzeit die ehemaligen DCL-Programmierer hin abwandern? Und vor allem: Wird man, wie es jetzt schon der Fall bei Proteus/DCL ist, auch VisualLisp demnächst das Prädikat 'Ungepflegt' verleihen müssen? Die Tatsache, dass das komplette VisualLisp-Paket von Version 2000i nach 2002 ohne die geringste Änderung und Pflege und sogar ohne Bugfixes übernommen wurde, spricht für sich.