The future of LT-Extender is : BricsCAD V13 !
 
This might be suprising for many users and developers - therefore we would like to document our conviction and our opinion - and simply, the facts ! - to all our users, developers and interested parties here, to point out the real and true alternative for AutoCAD LT and LT-Extender.
 
Some (explaining) details just ahead :
Since 2006 are we working together with the BricsCAD team for integrating our AutoLISP-Interpreter into BricsCAD V8. As two independent developer teams we have exchanged ideas and worked out solutions for the ARX -compatible C/C++ Interface (called BRX). And "last but not least" the BricsCAD team appreciated and consulted a lot our expertise regarding the common and particular AutoCAD compatibility.
 
For a long time (at least since 2002) we are carefully watching the area of so-called "AutoCAD-Clones" - to be prepared for the time after LT-Extender. Especially during the last 3,4 years, there were some most interesting and exciting developments in this area (keywords IntelliCAD, DwgLib, OpenDesignAlliance) which finally lead to the current situation : having BricsCAD as a real alternative for AutoCAD and AutoCAD LT in the CAD market.
 
So we will document and explain our opinion and our conviction here – as objective and comprehensive as possible.
 
Let's start with a review
 
When IntelliCAD software was first published (around 2000) as an efficient, powerful and capable so-colled "AutoCAD-Clone", the entire CAD world was quite excited, open-minded and full of hope - as this was the very first low-cost AutoCAD alternative ever (beside that more or less expensive MicroStation software).
Just a few years later there was and still is a large range of several derivates of core IntelliCAD - now organised in the ITC (www.IntelliCAD.org). It seems to be the main target to provide CAD software, which is easily to be adopted by AutoCAD experienced users, which means, the target is an AutoCAD like user interface and behaviour.
But just this orientation was and is (unfortunately !) the most important deficiency : there was and is no primary development target to provide an alternative platform not only for CAD users, but also and especially for CAD application developers; the reasons for are many.
 
1. these, after all, limited development resources;
caused by the situation of a multiple competition (on one side, AutoCAD as the big competitor, and on the other side those many IntelliCAD derivates as the small competitors) many developments, improvements and advantages became only part of particular IntelliCAD distributions and / or became part of the core IntelliCAD system either very late, or even never.
2. starting with AutoCAD R14, the ObjectARX programming interface was introduced by Autodesk; due to its heavy size and complexity, but also due to technical differences between the CAD systems, it was simply impossible to provide an analogon or similar API in the context of the IntelliCAD system.
 
Therefore, the number of applications which were ported to this IntelliCAD platform by the application developers was and still is rather small; this is still enforced by the fact that IntelliCAD's programming interfaces (APIs) - SDS, Lisp, COM, Diesel - are still more or less different from AutoCAD. So over all the years, IntelliCAD was (and still is) only less attractive for application developers, and it is still very complicate and taking huge efforts to provide a third-party application for both AutoCAD and IntelliCAD platforms - and many times, this is simply impossible for ARX based, COM based and VisualLisp based applications.
As the main result, one of the main rain reasons for that huge success of AutoCAD – the endless number of third-party applications - was withholded from IntelliCAD system  …
And finally, as another reason, the distribution of the IntelliCAD system as so many (more or less the same or slightly different) distributions prevented the growing or foundation  of a powerful counterpart to AutoCAD ... "divide et impera". Which user or developer is really able to distinguish between 10...15 InteliCAD distributions ??
 
Now, why especially BricsCAD ?
To speak about the main, simple reason : because BricsCAD, in the world of those AutoCAD compatible CAD sytems, is currently the only (and indeed, the very first ever) system which really provides all those  programming interfaces (APIs), as provided from AutoCAD, with an unrivaled, high level of compatibility. And because BricsCAD, for especially this reason, provides application developers with a real alternative to adopt their applications (designed for AutoCAD) with minimum afforts for an AutoCAD independent platform.
 
Bricsys provides a comprehensive documentation and overview on implemented programming interfaces (APIs) with its BricsCAD-Developer-Reference.
 
To say it in other words : because BricsCAD especially overcomes those limitations and problems of the IntelliCAD system. CAD users, applications and the application developers are respected as the nessecary unity which is nessecary for the success of the BricsCAD CAD system, as well for the success of CAD users and application developers.
With their decision, to restart the development of BricsCAD V8 from scratch, their were great opportunities to redefine the goals of V8 and to overcome old restrictions and limitations.
 
The main point of the new BricsCAD concept (in our opinion) is this :
The new BricsCAD is designed to address the maximum and perfect AutoCAD compatibility - for all parties : for the CAD users with provided commands, functions and system variables, and for the application developers and their applications with the unbeaten level of compatibility in all programming interfaces.
All available IntelliCAD based systems (as well as BricsCAD also) do provide a good Look & Feel - a user interface as known from AutoCAD; they all are more or less following the usual Windows design guides and rules ... so for AutoCAD users, there is virtually no difference in using the interface at all. But, this is not the main problem  - the main problem starts where third-party applications and programming interfaces are required !
 
To be most clear and precise : after nearly 10 years of IntelliCAD and IntelliCAD based "AutoCAD-Clones", with their restricted and limited programming interfaces, and therefore very few third-party applications only, it has been clearly proven and documented - without all those tiny, small, medium and big applications, and without even those countless number of little tools by the users themselves (using Lisp/VB/VBA), as used in the daily work, no CAD system has any chance at all to compete with AutoCAD.
 
And now, for the details
 
As already codumented here - the compatibility of application programming interfaces (APIs) - and even the compatibility of commands, options and system variables - is one of the most important details (and one of the most important development goals) for the new BricsCAD generation. Therefore we would like to have a closer look insight here; there are many and comprehensive informations at Bricsys website as well; we will provide links here as well, were appropriate.
 
Other than those IntelliCAD based CAD systems, it is the expressed and clear target for Bricscad development to provide (nealry 100%) sourcecode compatibility for all supported APIs - this means, that existing applications (designed for AutoCAD) will not need to be adjusted in their sourcecode, but rather immediately work with Bricscad (ADS/ARX based applications will only need to recompile, ideally); if nessecary, only very few adjustements in sourcecode needs to be done only, with veryless efforts.
 
So BricsCAD is able to provide the main advantage, that developers no longer need to manage different sourcecodes for AutoCAD and BricsCAD - but will be able to manage any potetial difference (if ever) in a single sourcecode ! It is this most important detail, which gives developers the real freedom and effectively allows application developers to provide  their application for BricsCAD as well ... one sourcecode for all CAD systems !
 
Because there seems to be a wide-spreaden kind of uncertainty regarding the several programing interfaces as used or provided by IntelliCAD based derivates, we will finally have a closer look at those APIs there, and will hopefully provide some clarification as well.
 
Programming Interfaces (APIs) in BricsCAD
 
DCL user interface :
this is available without any problem, and can be used and accessed by both AutoLISP and ADS/SDS applications
additionally, BricsCAD provides resizable DCL dialogs and ToolTips for buttons, images, listboxes etc. (both improvements do not break AutoCAD-compatibility !)
 
ADS/SDS:
 this interface has been available since a long time, and can be used as well. The SDK (Software Development Kit), as provided by BricsCAD, also includes Header files which will automatically redefine any "ads_xxx" function name to appropriate "sds_xxx" function name, so developers will not need to care about these details.
 
VBA / VB / COM:
 BricsCAD offers a completely AutoCAD compatible COM interface - this means, the COM object model itself is compatible with AutoCAD' COM object model. Additionally, BricsCAD also offers binary compatibility regarding the *.dvb files and fileformat. As result of this high level of compatibility, BricsCAD is able to load and run those *.dvb files which are designed for AutoCAD, and in turn, those *.dvb files created with BricsCAD can be loaded and run inside AutoCAD !
Tip: the only code adjustement(if nessecary) :
The main (root) COM application object as provided by BricsCAD is named "BricscadApp.AcadApplication", while AutoCAD uses "AutoCAD.Application"; to overcome the drawbacks of this difference, BricsCAD offers a configuration switch in "Settings" dialog : Program Options => System => "COMAcadCompatibility = 1"; when this option is activated, Bricscad additionally also registers as "AutoCAD.Application" with the COM system, and therefore, no VB/VBA/COM sourcecode adjustement is nessecary.
 
If there is no AutoCAD installed on the computer, Bricscad will detect this, and will automatically registeres itself as "AutoCAD.Application" as well.
 

AutoLISP:
Starting with the new BricsCAD V8, our AutoLISP-Interpreter (originally designed for LT-Extender, since AutoCAD LT 2004) has been integrated into BricsCAD - and has been evolved into a very stable, highly performant and highly compatible Lisp engine. Therefore, BricsCAD is able to provide the best platform for AutoLISP based applications, no known compatibility issues or problems.

main features of our "LispEx“ AutoLISP-Interpreter for BricsCAD:
 fully supports standard AutoLISP language set
 fully supports VisualLISP language set (vl/vlr functions)
 fully supports the COM based VisualLISP language set (vla/vlax functions)
very high performance - compared with both AutoCAD and IntelliCAD based systems (see and try our LispBenchmark)
FAS and VLX fileformat is not yet supported by "LispEx" - these fileformats use a particular lisp sourcecode encryption; to ensure Lisp code safety for developers, Bricscad can load encrypted Lisp file produced by both our DEScoder.exe as well as produced by Bricscad's own EncryptGui.exe utility; those encrypted Lisp files should be named as *.des.
 
TX (Teigha Runtime eXtension):
Another C++ programming interface is provided by that Teigha CAD engine (by OpenDesignAlliance) used by BricsCAD - this interface can be used by application developers, but the difference to ARX are significant, which requires and enforces a complete rewrite of any ObjectARX based sourcecode; please see this ARX/DRX comparision ...
 
BRX – the ObjectARX-sourcecode-compatible „BricsCAD Runtime eXtension :
This C++ programming interface is (currently) unique and exclusively available only with and for BricsCAD - based on the TX API, BricsCAD offers a completely ARX sourcecode compatible interface to all developers. Ideally, application developers will only need to recompile their application, using the BRX SDK ... even though this BRX interface is not yet finished (and therefore, can cause a few code adjustements still), it gets better and more complete with every day, based on developers' feedback - so it is only a question of time until fully completed, or at least, covering 95% of all ObjectARX based sourcecode.
A very good explanation of the BRX / TX Systems is provided by Bricsys as well.
 
In our estimation, it is especially this BRX programming interface, which is the major key for success, to attract application developers to the BricsCAD platform - and all the feedback from developers, porting their ARX based applications using BRX, clearly prove this.
 
For all the above mentioned reasons, it should be clear now, that it is our real pleasure to contribute to the BricsCAD development - we do not only care for our "LispEx" Lisp engine, but also contribute especially to the BRX system development. This way we can provide all our experience from 20 years of AutoCAD application development, but also our experiences from 7 years of LT-Extender development.
 
Programming Interfaces in IntelliCAD based systems
 
From our experience, and as well as from many users and developers feedback, there seems to be some confusion and uncertainty around the ARX and DRX, but also around the VB/VBA/COM programming interfaces - therefore, we would like to provide some clearity here.
 
IntelliCAD has a quite long development history, and for this reason, it has a number of proven, safe and stable programming interfaces : Lisp, DCL, SDS. But even though, there is many to remark here - and especially, regarding the more modern programming interfaces ARX and VB/VBA/COM.
 
Lisp:
Most of the IntelliCAD based systems use that original IntelliCAD Lisp engine - this Lisp engine only provides standard AutoLISP functions (like AutoCAD R14), but none of the VisualLISP extensions (vl-...), (vlr-...), (vla-...) and (vlax-...); very few of those IntelliCAD based systems, which we have tested (like "ZWCAD" or "CADian") do offer this VisualLISP extensions. Common to all these IntelliCAD derivates is, that this Lisp engines only provide a very poor performance, which is simply much to less for bigger AutoLISP applications and/or bigger AutoLISP data size, which drives such applications virtually unusable.
This can be verified by everyone using our LispBenchmark.

In contrast to the above mentioned, we are really proud to provide our AutoLISP-Interpreter "LispEx" for BricsCAD - combining a stunning performance with an unrivaled compatibility.
 
COM/VB/VBA:
All IntelliCAD based systems also offer a COM interface, including VB and VBA support. Unfortunately, the IntelliCAD COM object model in not compatible with the AutoCAD object model; this means, any COM based application sourcecode needs to be entirely rewritten, which in turn causes 2 different sourcecode streams, if both AutoCAD and IntelliCAD should be supported by the application. Additionally, the VBA code files *.vbi are not binary compatible with AutoCAD's *.dvb.

Since most IntelliCAD based systems are now based on that CAD core endine as provided by the OpenDesignAlliance, all those derivates now also offer that native COM interface as provided along with the ODA CAD core engine. This ODA COM object model is much closer to AutoCAD's original COM interface, but still not fully compatible and (due to the nature of a CAD core engine) not a fully complete COM object model.

The COM object model provided by Bricscad is fully AutoCAD compatible - even a binary fileformat compatibility is provided with the *.dvb files, as used by both AutoCAD and BricsCAD. Currently, BricsCAD's COM object model is not yet completely finished - a few interface classes are not yet implemented, but will follow in short terms.
 
ARX / TX / BRX:
Having a look at the IntelliCAD community, most confusion and uncertainty currently exists around the C++ programming interface "ARX" here - in almost all cases, this wrongly references to that (not ObjectARX compatible !) "TX" programming interface as provided by ODA's DwgDirect CAD engine; obviously, most IntelliCAD derivates misunderstand this "TX" system as the counterpart of "ARX", which is clearly not the case, or only in a very restricted context.
BricsCAD, in opposite, exclusively offers the BRX SDK - this BRX system is not only unique and exclusive in the world of AutoCAD compatible clones - it is especially fully ARX sourcecode compatible ! This offers all ARX application developers (for the very first time ever !) the great chance to use their existing ARX application sourcecode - and to provide a BricsCAD version directly by a simple recompilation (ideally, but sometimes few sourcecode adjustement is still nessecary, until BRX is completely finished), and to continue development with a single sourcecode stream only, for both AutoCAD and BricsCAD.
 
At BricsCAD/Bricsys websites you will find a very informative and clear BRX / TX comparision.
 
And finally : some personal words from our side …
As hard as this decision to terminate the LT-Extender-Software really was for us, and as much as we really regret this – there are some positive aspects as well :
1. the LT-Extender software (with AutoCAD LT) is no longer a competitor for BricsCAD,
and we can fully concentrate our complete development resources on BricsCAD development
2. the termination of LT-Extender could be final the trigger for many CAD users and for many application developers to give BricsCAD a real chance and to provide the applications for BricsCAD.
 
Naturally, we will offer and provide any suitable support, assistance, help, for all users and developers, in any requested and desired way, around the subject of "BricsCAD" - this is not only promised, this is guaranteed here !
 
Of course, we really hope that as many users and developers as possible will give BricsCAD a try ... maybe, right now, and/or another try after few months (as BricsCAD gets better with every day !), and take BricsCAD into account in their plannings. But at least, we are sure (and hope, we did verify here, why we are convinced) :  if there is an alternative to AutoCAD today - then it is BricsCAD. But wether Bricscad will become the main counterpart - this depends on the CAD users and especially on the application developers ... we will provide all our best, in the interests of all.