Fact 1: ObjectARX is a SDK developed by Autodesk and is used to build plug-ins for AutoCAD.
Fact 2: DRX is a SDK developed by the Open Design Alliance and is used to build plug-ins for DWGdirect hosted applications, which may or may not be AutoCAD clones.
Fact 3: BRX is an ObjectARX source compatible SDK developed by Bricsys and is used to build plug-ins for Bricscad by recompiling the source code of an AutoCAD plug-in.
Fact 4: Argon is an another ObjectARX source compatible SDK developed by Graebert and is still in Alpha.
Fact 5: ObjectDRX is something I recently came across and have not yet figured out.
On January 6th, ZWSOFT, a Chinese IntelliCAD developer, released ZWCAD 2009. Their press release mentioned an “improved DRX programming interface, similar to ARX in AutoCAD”. Listed below are sections of the ZWCAD 2009 product documentation (verbatim) that refer to something called ObjectDRX.
“ObjectDRX is a ZWCAD platform re-development environment. So long as the user follows ObjectDRX the API interface, class and the agreement, can develop own command, and uses in the ZWCAD platform. These re-development command and in the ZWCAD platform provides the command in uses and in the efficiency has not distinguished.”
So I guess now you know why I have not figured it out yet. I will get to the “agreement” mentiond here later, but let’s consider another statement.
“ObjectDRX in the environment configuration, only needs to contain three head files, can carry on the development. But ObjectARX needs to contain the different head file and the LIB according to the characteristic. Therefore, the ObjectDRX simple configuration, is very suitable beginner to use.”
The plot thickens. A comparison with Autodesk’s ObjectARX gives an indication that ObjectDRX may be another ObjectARX source compatible SDK. Now let’s see the “OpenDRX Development Agreement” that was mentioned ealier.
1. Suppose user has certain C++ development experience;
2. Suppose user has certain understanding to ZWCAD;
3. Suppose user understands ZWCAD the platform’s SDS pattern development;
4. In the guide the demonstration code and the example use the vc2003.net compilation, but had not defined that the re-development the language environment are vc2003.net.
1. Suppose user understands ObjectARX development method;
2. Suppose user understanding dynamic link library performance development method;
3. Suppose user is familiar with the windows application program development method.
That’s it. That’s the entire agreement. I am not sure who is agreeing to whom and what is being agree to here. Anyways, lets dig a bit deeper. In a section titled “ObjectDRX Application Basics” I see the following statement.
“Should better have the ARX re-development experiences, but this is not necessarily.”
Then there are numerous references to the ODA’s DRX SDK and sample code which leads me to believe that the ObjectDRX SDK is actually a SDK that wraps around the ODA’s DRX SDK. Whether it is actually source compatible with ObjectARX is not clear, but judging from what I managed to understand from this literature, it certainly seems that way.
Long story short, since the ODA does not appear to be in the mood to make their DRX SDK source compatible to Autodesk’s ObjectARX SDK, companies like Bricsys, Graebert and now ZWCAD are going ahead and doing it themselves. I don’t believe it it will be very difficult for the ODA to make DRX source compatible with ObjectARX, but judging by the kind of litigating mood that Autodesk’s is in right now, the ODA may be doing the wise thing. However, a recent press release from Bricsys announcing 34 AutoCAD plug-ins that were successfully ported to Bricscad using the BRX SDK seems to suggests that their efforts are finally paying off.
With DoubleCAD around the corner, IntelliCAD 7 further down the road and Bricsys, Graebert and ZWSOFT going to lengths to get the attention AutoCAD plug-in developers, it looks like the fight for the AutoCAD pie is heating up. It may very well be that this global economic meltdown is the last straw for some AutoCAD customers, unless AutoCAD 2010 gives them good enough reason to stay on. Or unless these new AutoCAD clones and their plug-ins fail to shirk off the “unreliable” and “unstable” tags that Autodesk marketing has put on them, rightly or wrongly. In any case, I don’t think the “cheap” tag will work in Autodesk’s favor this time around.