Die Zukunft des LT-Extender ist : BricsCAD V13 !
 
Dies mag für viele Anwender und Entwickler überraschend kommen – für einige sicherlich weniger; daher möchten wir nun allen Interessenten und Lesern unsere Positionen, Einschätzungen und Ansichten darlegen, mit dem einen Ziel : Anwendern und Entwicklern von AutoCAD LT und LT-Extender eine echte Alternative aufzuzeigen.
 
Ein (er)klärendes Detail vorab:
Seit 2006 arbeiten wir mit dem BricsCAD-Entwickler-Team zusammen. Schwerpunkt hierbei war und ist hier unser AutoLISP-Interpreter, welcher in Bricscad seit Version V8 integriert ist, sowie die Entwicklung einer ARX-SourceCode-kompatiblen C++ Programmier-Schnittstelle;  als unabhängige Partner tauschen wir Software und Ideen aus, und arbeiten gemeinsam an technologischen Lösungen für das ARX-kompatible C/C++ Interface für Bricscad (BRX genannt). Und „last but not least“ konsultiert uns das BricsCAD-Entwickler-Team wegen unserer Erfahrungen bezüglich der allgemeinen und umfassenden AutoCAD-Kompatibilität.
 
Seit langer Zeit (mindestens seit dem Jahre 2002) beobachten wir den Bereich der sogenannten „AutoCAD-Clones“ sehr aufmerksam – um auf die Zeit nach dem LT-Extender vorbereitet zu sein. Insbesondere in den letzten 3,4 Jahren wurden in diesem Bereich (Stichwort IntelliCAD / DwgLib / OpenDesignAlliance) sehr interessante Entwicklungen und Fortschritte gemacht, welche es nun ermöglichen, mit BricsCAD V9 endlich eine ernsthafte Alternative zu AutoCAD und AutoCAD LT im CAD Markt zu haben.
 
Nachfolgend wollen wir diese, unsere Überzeugung detailliert darlegen – so objektiv wie möglich, und so umfassend wie möglich.
 
Beginnen wir mit einem kleinen Rückblick
 
Als mit der IntelliCAD-Software (ca. im Jahre 2000) erstmals ein leistungsfähiger AutoCAD-Clone verfügbar war, stand die CAD-Welt dem sehr aufgeschlossen und hoffnungsvoll gegenüber – war doch damit erstmals eine preiswerte Alternative verfügbar (neben dem nicht so preiswerten MicroStation).
Bereits nach wenigen Jahren gab es eine große und umfangreiche Palette verschiedenster Varianten und Derivate von IntelliCAD – organisiert im ITC (www.IntelliCAD.org). Der Schwerpunkt der Entwicklung war und ist darauf ausgerichtet, eine Software anzubieten, welche für Anwender mit AutoCAD-Erfahrung so einfach (d.h. so AutoCAD-konform) wie möglich anwendbar ist.

Genau hierin liegt jedoch (leider !) auch das größte Manko : es war und ist kein primäres Entwicklungsziel, neben den Anwendern auch den Applikations-Entwicklern eine alternative Plattform anzubieten; die Gründe sind vielfältig :
 
1. die letztlich begrenzten Entwicklungs-Ressourcen;
die mehrfache Konkurrenz-Situation (zum einen AutoCAD als die große Konkurrenz, zum anderen aber auch die vielen IntelliCAD-Varianten als die kleine Konkurrenz), wodurch positive Entwicklungen und Verbesserungen entweder nur Bestandteil bestimmter Distributionen bleiben und/oder nur sehr spät (oder eben auch gar nicht) als Bestandteil des Basis-IntelliCAD wurden;

2. mit AutoCAD R14 wurde ObjectARX als Applikations-Plattform durch Autodesk eingeführt; wegen dessen enormer Größe und Komplexität, aber auch wegen der technologischen Unterschiede zwischen den CAD-Systemen, war es schlicht unmöglich, hierfür ein Pendant im Rahmen des IntelliCAD-Systems zu entwickeln;

Damit blieb die Anzahl der Applikationen, welche durch die Applikations-Entwickler für die  IntelliCAD-Plattform angepaßt und bereitgestellt wurden und werden, entsprechend gering; zusätzlich wird dies auch dadurch erschwert, daß sich alle Programmierschnittstellen (APIs) in IntelliCAD – SDS, Lisp, COM, Diesel – mehr oder weniger stark von AutoCAD unterscheiden. Somit blieb IntelliCAD nur mäßig attraktiv für Entwickler, und es war (und ist) für Entwickler äußerst schwierig und enorm aufwändig, ihre Applikationen für AutoCAD und IntelliCAD parallel anzubieten.

In der Konsequenz bleibt eine der entscheidenden Grundlagen für den enormen Erfolg der AutoCAD-Software – die riesige Palette der Zusatz-Applikationen – dem IntelliCAD-System vorenthalten …

Und nicht zuletzt verhindert die Zersplitterung des IntelliCAD-Systems in so viele (mehr oder weniger gleiche bzw. verschiedene) Derivate die Schaffung oder Entstehung eines Gegenpols zu AutoCAD … „divide et impera“. Welcher Anwender oder Entwickler kann ernsthaft zwischen 15...20 IntelliCAD-Derivaten entscheiden ??
 
Warum nun gerade BricsCAD ?
Um es ganz einfach zu sagen: weil BricsCAD in der Welt der AutoCAD-kompatiblen CAD-Systeme das einzige System ist, welches praktisch alle in AutoCAD vorhandenen Programmierschnittstellen, in hochgradig kompatibler Form, zur Verfügung stellt. Und eben dadurch erstmals auch für Applikations-Entwickler eine echte Alternative bietet, vorhandene Applikationen, welche für AutoCAD entwickelt wurden, mit minimalem Aufwand auch für BricsCAD verfügbar zu machen.
 
Eine umfassende Übersicht zu den Programmierschnittstellen finden Sie in der BricsCAD-Developer-Referenz (in Englisch).
 
Oder, um es mit anderen Worten darzustellen : weil BricsCAD erstmalig eben genau die oben beschriebenen Problemfälle des IntelliCAD-Systems beseitigt. Anwender, Applikationen und Applikations-Entwickler werden als die notwendige Einheit betrachtet und respektiert, welche erforderlich ist für den Erfolg, sowohl von BricsCAD, als auch der Applikationen, Entwickler und Anwender.

Mit der Entscheidung, BricsCAD V8 von Grund auf neu zu entwickeln, ergaben sich verschiedenste Möglichkeiten, alten „Ballast über Board“ zu werfen, als auch die Zielrichtung von BricsCAD neu zu definieren.
 
Der (unserer Meinung nach) entscheidende Punkt im neuen Konzept:
Das neue BricsCAD setzt kompromiß- und bedingungslos auf maximale Kompatibilität zu AutoCAD – sowohl in den für die Anwender verfügbaren Befehlen, Funktionen, Systemvariablen, aber auch bzgl. der für Applikations-Entwickler und Applikationen so extrem wichtigen Kompatibilität in den Programmierschnittstellen.

In praktisch allen IntelliCAD-basierten Derivaten (und natürlich auch in BricsCAD) ist die Bereitstellung einer AutoCAD-kompatiblen Benutzeroberfläche seit Jahren kein Problem mehr – Anwender von AutoCAD finden sich meist sofort „heimisch“; dies ist auch nicht das eigentliche Problem … dieses beginnt dort, wo Zusatz-Applikationen und Programmierschnittstellen erforderlich werden.

Um es präziser zu formulieren : ca. 10 Jahre IntelliCAD, mit den beschränkten Programmierschnittstellen, und daraus resultierend wenigen Applikationen, haben es eindeutig und unzweifelhaft gezeigt : ohne die kleinen, mittleren und großen Applikationen, aber auch jene unzähligen kleinen Utilities und Tools, welche durch erfahrene Anwender im Berufsalltag selbst erstellt werden (mit AutoLISP/VB/VBA), hat keine CAD-Software eine Chance, gegenüber AutoCAD zu bestehen.
 
Nun zu den Details
 
Wie bereits dargestellt, spielt die Kompatibilität der Programmierschnittstellen (und auch der Befehle, Optionen, Systemvariablen etc.) eine ganz zentrale Rolle in BricsCAD. Daher wollen wir hier etwas detaillierter auf diese Punkte eingehen; auch auf den Websites von www.bricsys.com finden sich viele Hinweise hierzu, wir werden auch direkt darauf verweisen.
 
Im Gegensatz zu allen IntelliCAD-basierten Derivaten, ist es das erklärte Ziel für BricsCAD, eine maximale (nahezu 100%ige) Sourcecode-Kompatibilität bereitzustellen dies bedeutet, dass vorhandene Applikationen eben nicht im Sourcecode angepasst werden müssen, sondern vorhandene Applikationen direkt auch in BricsCAD arbeiten (ADS/ARX-Anwendungen müssen im Idealfall nur neu kompiliert werden); ggf. erforderliche, minimale Anpassungen können direkt im eigentlichen Sourcecode vorgenommen werden.
 
Es ist hierbei entscheidend, daß Applikations-Entwickler eben nicht mehr verschiedene Sourcecodes (für verschiedene Zielsysteme) pflegen müssen erst dieses entscheidende Detail bietet für Entwickler die Möglichkeit, ihre Applikationen mit minimalem Aufwand für das BricsCAD System zu portieren.
 
Da zugleich eine gewisse Unsicherheit bzgl. der diversen Programmierschnittstellen in den verschiedenen IntelliCAD-basierten Derivaten weit verbreitet scheint, werden wir am Ende auch noch einen Blick darauf werfen, und hoffentlich etwas Klärung bieten.
 
Programmier-Schnittstellen in BricsCAD
 
DCL Oberflächen:
sind problemlos verfügbar, und von AutoLISP als auch von ADS/SDS Applikationen aus nutzbar;
zusätzlich bietet das BricsCAD DCL auch frei skalierbare Dialogboxen, und ToolTips (beides, ohne die AutoCAD-Kompatibilität zu verletzen !) 
 
ADS/SDS:
diese Programmierschnittstelle steht seit langer Zeit zur Verfügung, und ist ebenfalls problemlos nutzbar. Das durch BricsCAD angebotene SDK (Software Development Kit) beinhaltet u.a. auch Header-Dateien, welche eine automatische Namensanpassung vornehmen.
 
VBA / VB / COM:
BricsCAD bietet erstmals ein vollständig AutoCAD-kompatibles COM-Objekt-Modell an. Zusätzlich besteht aber auch Kompatibilität im Dateiformat *.dvb ! Dies bedeutet, dass BricsCAD jene für AutoCAD erstellten *.dvb Dateien laden und ausführen kann, und jene für BricsCAD erstellten *.dvb Dateien auch in AutoCAD geladen und ausgeführt werden können.
Tip: einzige ggf. erforderliche Anpassung:
das COM-Applications-Object wird in BricsCAD als „BricscadApp.AcadApplication“ angemeldet, in AutoCAD als „AutoCAD.Application“; alternativ kann in den BricsCAD-Einstellungen aber auch einmalig die Option : Programm-Optionen => System => „COMAcadCompatibility = 1“ aktiviert werden, dann meldet sich BricsCAD zusätzlich auch als „AutoCAD.Application“ im COM-System an, und es sind keine Änderungen am VB/VBA/COM Sourcecode erforderlich.
 
Ist kein AutoCAD parallel installiert, so erfolgt dies übrigens automatisch.
 

AutoLISP:
Seit Version V8 ist unser (für den LT-Extender, ab LT 2004 entwickelter) AutoLISP-Interpreter integriert – und hat sich im Laufe der Zeit zu einem ausgesprochen stabilen und sehr schnellen System entwickelt. Damit können wir in BricsCAD sicherstellen, daß praktisch keine Kompatibilitäts-Probleme beim Einsatz bestehender AutoLISP-Applikationen unter BricsCAD bekannt sind.

Hier die wichtigsten Leistungsmerkmale unseres „LispEx“ AutoLISP-Interpreters in Bricscad:
volle Unterstützung des Standard-AutoLISP Sprachumfanges
volle Unterstützung des VisualLISP Sprachumfanges (vl/vlr Funktionen)
volle Unterstützung des COM basierten
VisualLISP Sprachumfanges (vla/vlax Funktionen)
sehr hohe Performance – sowohl im Vergleich mit den IntelliCAD-Derivaten, als auch im Vergleich mit AutoCAD (siehe unseren LispBenchmark).
nicht unterstützt werden das FAS und VLX Dateiformat – dies ist eine spezifische Verschlüsselung des Lisp-Codes; in BricsCAD kann unser „LispEx“ Interpreter die durch unseren DEScoder.exe, als auch jene mit den BricsCAD-eigenen EncryptGui.exe verschlüsselten Lisp-Dateien laden. Diese verschlüsselten Lisp-Dateien sollten als *.des erstellt werden.
 
TX (Teigha Runtime eXtension):
eine weitere C++ Programmierschnittstelle wird durch den in BricsCAD integrierten CAD-Kernel der ODA (OpenDesignAlliance) bereitgestellt – diese Schnittstelle kann durch Entwickler genutzt werden; die Unterschiede zu ObjectARX sind allerdings erheblich (siehe auch diese Gegenüberstellung), und erfordern zwangsweise eine Neuprogrammierung bestehender ARX-Applikationen.
 
BRX – die ObjectARX-Sourcecode-kompatible "BricsCAD Runtime eXtension" :
diese C++ Programmierschnittstelle ist momentan einzigartig und exklusiv nur mit und für BricsCAD verfügbar – basierend auf dem TX API, bietet BricsCAD allen ARX-Entwicklern eine vollständig ObjectARX-Sourcecode-kompatible Programmierschnittstelle an ! Entwickler brauchen damit im Idealfall nur ihre Applikationen neu zu kompilieren … auch wenn das BRX System noch nicht vollständig ist – der Umfang des durch BRX abgedeckten Umfanges des ObjectARX SDK wächst täglich.
Eine sehr gute Darstellung des BRX / DRX Systems wird auch durch Bricsys bereitgestellt.
 
Unserer Meinung nach ist das BRX System einer der entscheidenden Schlüssel zum Erfolg – und das Feedback jener ARX-Entwickler, welche ihre Applikationen mit BRX auf BricsCAD übertragen, bestätigt dies in erfreulicher Weise … auch die Liste der bereits portierten Applikationen wächst täglich !
 
Und so ist es sicher verständlich, daß es uns eine ausgesprochen große Freude ist, neben unserer Arbeit am AutoLISP-Interpreter, insbesondere hier bei der BRX Entwicklung teilzunehmen, und so unsere 20-jährige Erfahrung als Applikations-Entwickler, aber auch die Erfahrungen aus 7 Jahren LT-Extender, einfließen lassen zu können.
 
Programmier-Schnittstellen in IntelliCAD-basierten Derivaten
 
Nach unseren Erfahrungen, und aus Feedback seitens der Anwender und Entwickler, scheint momentan eine erhebliche Verwirrung und Unsicherheit rund um die Programmier-Schnittstellen ARX/TX, aber auch bzgl. VB/VBA/COM, zu bestehen … daher wollen wir hier etwas zur Klärung beitragen.
 
IntelliCAD hat eine relativ lange Entwicklungsgeschichte, und ist entsprechend ausgereift. Gleiches gilt natürlich auch für die „klassischen“ Programmier-Schnittstellen : Lisp, DCL, SDS. Dennoch gibt es einige Anmerkungen hierzu … Gleiches gilt um so mehr für die neueren Programmier-Schnittstellen ARX und COM/VB/VBA.
 
Lisp:
Die meisten IntelliCAD-Derivate nutzen jenen AutoLISP-Interpreter, welcher in IntelliCAD stets integriert ist – dieser bietet jedoch nur Standard-AutoLISP (Release 14) – jedoch keine (vl-...), (vla-...), (vlax-...) und (vlr-...) Funktionen; von den unsererseits getesteten IntelliCAD-Derivaten bieten nur „ZWCAD“ und „CADian“ diese VisualLISP-Funktionen.
Allen gemeinsam ist jedoch, daß die Performance dieser Lisp-Interpreter ausgesprochen schlecht ist, und für größere Lisp-Applikationen und/oder größere Datenmengen praktisch unbrauchbar ist.
Dies kann mit unserem LispBenchmark sehr einfach überprüft werden.

Demgegenüber bietet unser, in BricsCAD integrierter, Lisp-Interpreter („LispEx“) eine unerreichte AutoLISP-Kompatibilität bei gleichzeitig ebenso hoher Performance.

COM/VB/VBA:
Auch praktisch alle IntelliCAD-Derivate bieten ein COM-Interface an. Das IntelliCAD-COM-Objektmodell ist jedoch nicht kompatibel zum AutoCAD-COM-Objektmodell; dies bedeutet, daß COM-basierte (Delphi, VB, VBA, etc.) AutoCAD-Applikationen komplett neu programmiert werden müssen. Zusätzlich sind die in IntelliCAD genutzten *.vbi VBA-Programmdateien nicht kompatibel zu den AutoCAD genutzten *.dvb Dateien.

Seit geraumer Zeit integrieren einige IntelliCAD-Derivate zusätzlich auch das COM-Objektmodell der TX-CAD-Engine (siehe TX und OpenDesignAlliance) – dieses zusätzliche COM-Objektmodell orientiert ist deutlich näher am AutoCAD-Objektmodell, ist aber (naturgemäß) ebenfalls nicht vollständig, und nicht vollständig kompatibel.

Demgegenüber bietet das durch BricsCAD angebotene COM-Objektmodell eine praktisch 100%ige Kompatibilität zum AutoCAD-Objektmodell (einige wenige Funktionen sind noch nicht vollständig implementiert, kommen aber in Kürze), sowie zusätzlich auch Datei-Kompatibiltät bzgl. der *.dvb Dateien.

ARX / DRX / BRX:
Rund um die C/C++ Programmier-Schnittstelle „ARX“ herrscht die meiste Verwirrung … in den allermeisten Fällen ist aber jene (nicht ARX-kompatible !) TX-Programmier-Schnittstelle der OpenDesignAlliance gemeint; offensichtlich verstehen viele IntelliCAD-Derivate das TX-System als das ARX-Analogon seitens der OpenDesignAlliance; genau dies ist jedoch nur sehr beschränkt der Fall!

BricsCAD bietet dagegen exklusiv das BRX SDK an – das BRX-System ist nicht nur einzigartig (im Bereich der AutoCAD-“Clones“), es ist vor allem ARX-Sourcecode-kompatibel ! Damit besteht erstmalig für ARX-Entwickler die Chance, die für AutoCAD entwickelten Applikationen mit einfacher Rekompilierung für BricsCAD zu portieren – und zukünftig mit einem einzigen (gemeinsamen) Sourcecode beide Zielsysteme zu bedienen.
 
Auf den Bricsys Websites finden Sie hier eine sehr gute Gegenüberstellung.
 
Und noch ein persönliches Wort am Ende …
So schwer uns die Entscheidung zur Einstellung der LT-Extender-Software auch gefallen ist – es liegen hierin auch einige positive Aspekte:

1. der LT-Extender (mit AutoCAD LT) ist nun keine Konkurrenz mehr für BricsCAD ,
wir können unsere gesamten Entwicklungs-Kapazitäten nun exklusiv auf BricsCAD konzentrieren

2. der Wegfall des LT-Extender kann für viele Anwender und Entwickler der Anlass sein, um BricsCAD eine Chance zu geben, bzw. die Applikationen für BricsCAD bereitzustellen.
 

Und selbstverständlich bieten wir allen Anwendern und Entwicklern jede erdenkliche Unterstützung, in jeder gewünschten Form, zum Thema „BricsCAD“ an – dies ist nicht nur versprochen, dies ist garantiert !

 
Natürlich hoffen wir, möglichst viele Anwender und Entwickler bewegen zu können, BricsCAD zumindest einmal zu testen und/oder mittel- und langfristig in die Planungen einzubeziehen. Zugleich sind wir aber zutiefst davon überzeugt (und konnten dieses hoffentlich auch hinreichend belegen) : wenn es eine Alternative zu AutoCAD gibt oder geben kann, so ist es BricsCAD – ob es dies letztendlich wird, hängt auch von Anwendern, und ganz besonders, von Applikations-Entwicklern ab … wir werden jedenfalls alle unsere Möglichkeiten einbringen !