The DataCAD Developer Network (DDN) is an online resource for information and support for DCAL® (DataCAD Applications Language) developers as well as anyone interested in creating fonts, toolbars, hatch patterns, or linetypes for use in DataCAD.

Moderator: pjdixit

#77165 by Joseph Baron
Tue Oct 29, 2019 9:26 am
Does anyone have any information on specific DCAL compiler limitations?

For example I am finding that I cannot have in a DCS file:
1. More that 50 calls to the same custom procedure.
2. More than 160 calls to the same builtin procedure.
3. Adding comments within the above can affect successful compiling.

While I haven't tested this extensively I am finding that sometimes it's a mystery why a DCS file will not compile without errors so I am looking for anything that can help me pinpoint why it won't get through the compiler.

Some of the errors include 'Doubly defined error' or 'Unable to add external reference'.

So is there limit on the maximum number of characters in any one Procedure/Function? The DCI & DCO files are small around 18KB.

Thanks in advance!
#77166 by dhs
Tue Oct 29, 2019 1:48 pm
Hi Joseph,

There appear to be some quite extensive memory limitations in the DCAL compiler. I have come across the ''Unable to add external reference' all too often, but I can't say I'm familiar with the 'Doubly defined error' message.

I assume you are compiling/linking with the dcc1 & dcc2 commands (rather than the one-step dcc command). If not, that is the first thing to try.

You may also want to take a look at the environment where you are doing the compiles. Obviously the compiler does not work at all on 64 bit systems, but it appears to me that some of the more recent 32 bit Command Line implementations left less memory heap available for the running application than the earlier versions of MS-DOS. I use DOSBox for any DCAL compiles I need to do not only because it allows me to run the compile on a 64 bit machine, but also because it appears to be quite a lean DOS implementation (dcs files that get a heap overflow error in a Command Line window on my old Win 7 laptop will compile without problem using DOSBox on my Win 10 machine)

I have never bothered to try to come up with the actual numbers, but there is certainly a limitation on the number of external calls that you can have in a single dcs file (I've never realised that this also applied to BUILTIN procedures, but obviously you have found a limitation there also).
There are 2 ways around this limitation:
1. You can split your single dcs file into multiple modules. My SpacePlanner macro ended up with over 20 separate modules as a result of the need to do this ... this then caused problems with the DCL linker which appeared to only recognise the first 128 characters of the command line parameters (I initially thought this was a DOSBox limitation but I am by not means certain ... it may be a limitation of the DCL compiler itself or even a DOS limitation ?? ... it occurred even when using a .lnk file). The result of this command line limitation was that I needed to shorten the names of my source files so that I could fit all their names in 128 characters (e.g. 'SPlanner.dcs' became 'SP.dcs' and so on).
2. Rather than having multiple calls to the same external procedure you can create a local procedure that calls the external one and then call that local procedure from multiple places in your code. I used this approach for much of my logging logic in Space Planner and an example code snippet is shown below:
Code: Select allPROCEDURE MyLogStr (str : string);
! Added this proc to reduce number of external references
   LogStr (str);
END MyLogStr;
In the above example LogStr is an external call, but I only call it once (in the code shown). There are then multiple calls to MyLogStr thoughout the code.

I have also found that sometimes a linker error can be solved by changing the order of the modules in the dcl parameters. This is pretty much a last resort and in most cases will not fix a problem (but on occasion it has worked when all else fails).

I hope you manage to get around all the DCAL compiler/linker limitations, but those limitations (and the logical gymnastics you sometimes have to go through to get around them) are certainly one of the reasons why I have turned to D4D for any particularly complex macro development (although I think there is still a place for Classic DCAL as it can do a few things that D4D cannot ... see the comparison page on my website)
#77167 by Joseph Baron
Tue Oct 29, 2019 4:37 pm
Thanks David for your quick response,

I find that I can get up to 256 chars in a LNK file and that has become a limiting factor when adding more into a DCAL macro.

I tried your local procedure tip (thank you for that!) and it did help when adding more to source file before it brick walled again.

For this particular file it allowed almost double the calls I had, going from 60 to 114, so that's a good way to reduce when the available mem is running short.
#77168 by dhs
Tue Oct 29, 2019 9:10 pm
I can get up to 256 chars in a LNK file
... obviously the 128 char limit is a limitation of DOSBox then (or at least of the version of DOS it implements).
With 256 chars you could have over 90 modules by using 1 and 2 character file names (not that I would necessarily recommend that ... I suspect you may run into other limitations with that many modules quite apart from the 'readability' of the file names).

Only other thing I can think of is if you have a lot of constant values hard-coded then it may be helpful to remove those and read them from a file as required (e.g. button labels or messages displayed to the user etc.), or even to compromise the usability a little by getting rid of non-essential items such as lblmsg calls etc. I'm really not certain if that would help much (or at all), but it is something I would try (but note that the maximum variable size is 32k in DCAL so if you're reading strings into an array of str255 for example the maximum size of the array is 127 ... in my SpacePlanner macro I have a module that reads a whole lot of strings into arrays every time the macro is invoked and then other modules simply pass the array index number to make use of those strings ... MFM pointed out in a recent post about Roofit Macro you only really need to read the strings into the array the very first time the macro is run, although that means that changes to the text files will not reflected unless you get a 'fresh' version of the macro)

I can certainly sympathise with the limitations you are experiencing, but I'm not sure that I can offer much more advice other than to perhaps consider splitting the functionality across 2 discreet macros (although if you are having trouble compiling the individual modules then that may not actually help any).
#77172 by Joseph Baron
Wed Oct 30, 2019 6:14 am
Thanks David,

I am using DOSBox on a windows 7 x64 machine, and I can put up to 256 chars in a LNK file. I haven't put DOSBox on my windows 10 machine yet to see if it's the same.

I use a lot of pnttarr() and polar() calls in addition to custom procedures that draw a lot of lines and dimensions with an INI file that holds a lot of variables. I prefer the file names to be recognizable and do try to keep them short, and as you say I have 'split' things that I could not fit into one across two different but similar macros.

When the limitations do occur most of the time I start poking things into nested procedures that while it breaks up the code it does allow me to continue adding additional lines into existing code and get it through the compiler.

I do plan to get into D4D, I guess the Community Edition Delphi version that Embarcadero has is a good place to start.

Who is online

Users browsing this forum: No registered users and 0 guests

About DataCAD Forum

The DataCAD Forum is a FREE online community we provide to enhance your experience with DataCAD.

We hope you'll visit often to get answers, share ideas, and interact with other DataCAD users around the world.


Software for AEC Professionals Since 1984