How to bypass the main difficulties in porting CAD applications to nanoCAD?

At the end of October 2014, the 10th anniversary conference “Software Development, CEE-SECR-2014” was held in Moscow, where our report on the creation of cross-CAD software was presented. The report consisted of a historical review, a story about the experience of porting CAD applications to nanoCAD and an analysis of the main difficulties in porting. In this article we will not dwell on the first two parts of the report - the entry was published at the end of the article, and we will take a closer look at the third part, which was finalized as a result of the discussion of the report on the sidelines of the conference.

When in 2008 we started developing nanoCAD, we already had more than two dozen AutoCAD applications. Works on porting applications were conducted in parallel with the development of a new CAD system, the requirements of the applications largely determined the direction of development. As a result of porting, applications have become cross-CAD-platform, have earned in nanoCAD and have not lost the opportunity to work in AutoCAD.
')
In the process of porting our own applications, as well as in the process of communicating with developers of third-party applications within the nanoCAD Developers Club, we found several repetitive patterns that hinder effective porting:

1. Waiting for API to “grow”
2. Unwillingness to use a workaround solution that works in all systems
3. Use of side effects

Template 1. Waiting for API to “grow”

Periodically, we are faced with the fact that after the first unsuccessful attempt to port an existing application, the developer disappears, at best, by writing: “I will wait until you finish the API”, without telling exactly what did not work out. Fortunately, not everyone does this, and with each release of nanoCAD, we publish a list of API improvements requested by members of the nanoCAD Developers Club through the Club’s bug tracker.

Our experience shows that all applications basically use the same API functions, but each application has its own specific needs. This situation is shown schematically in the figure, where the central part is the commonly used API, and the “paths” are specific needs. The diagram shows that the implementation of specific functions for one application in nanoCAD, as a rule, does not lead to the appearance of specific functions needed by another application.



From here it becomes clear why the “Let's wait until the API grows” approach does not work: if we do not know about the existence of a compatibility problem, it will not be fixed.



Solution: Sign up for the Developer Club and create tasks for revision in the bugtracker.

Pattern 2. Unwillingness to use a workaround solution that works in all systems.

Original image

Strictly speaking, this pattern is a special case of pattern 1, but it is so common that it makes sense to consider it separately.

Often there is a workaround that works in all CAD platforms. In this case, the request for refinement is likely to be postponed, since it is obvious that other problems with no workarounds have higher priority.

Solution: Is there a workaround? Use it!

Pattern 3. Using side effects

Original image

Side effects in different CAD platforms are different.

Abstract example: It is found that the print function can multiply numbers. You should not use it for multiplication, in another platform this effect may not be.

Life example: In ObjectARX, after closing an object using the pEntity-> close () method, you can call some methods of an already closed pEntity object. This is contrary to the ObjectARX documentation, but it works. In nanoCAD, after calling pEntity () -> close (), the object is destroyed and subsequent calls lead to a crash. If the application is aligned with the documentation, it starts to work in both platforms.

Solution: No side effects! Use the functionality for its intended purpose.

findings

Small applications that use the commonly used part of the API can be ported to nanoCAD with minimal or no changes.

Porting a complex application often requires both refinement of the missing functionality on the part of the platform, and making changes to the application. These changes, as a rule, are refactoring and do not lead to loss of compatibility with AutoCAD. As a result, the resulting application is built from the same source code for both nanoCAD and AutoCAD.

The developer club bugtracker is a way to influence the development of the nanoCAD API. The more developers will vote for a particular API function, the sooner it will be implemented.

Report recording and presentation

Link to the presentation: www.slideshare.net/islobodin/ceesecr2014-41467249 .

You can also discuss the article on our forum .

PS In addition to the last slide, we cannot but share a link to the article “CAD in the USSR, or Kievnauchfilm Presents” , which would have necessarily entered the presentation if it had been published before the report.