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 dieIntelliCAD-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.
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.
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 !