What settings are needed to debug and compile a dll ?

Zemax has the wonderful ability to add user-defined surfaces and objects, but they have to be compiled by the user into a dll. With the Community version of Visual Studio 2019, does anybody know (a) which components of Visual Studio need to be installed, (b) what settings are needed in order to “Attach to Process…” in order to debug, and (c) what settings are needed to compile routines correctly.

The background here is that the user has to look through a set of examples to work out how to do anything, and these are mostly in C, probably from 20 years ago. There are 2 very useful articles about how to compile a dll, and debug a dll, but they are for C++, with no explanation about when and why C++ is needed. Some VS2017 compiler settings are given, but a lot of others are not mentioned, and there is no information about how to install Visual Studio. The ability to debug a file is phenomenal, but they do not attach with VS2017 and VS2019, and there is a message that “A Development License is required…”. What are the installation requirements, and the settings, in order to debug in the recent VS versions? Separately, and a reason for needing debugging to work, some code that worked with one type of surface did not work with another type. Ultimately the problem went away when the code was converted to C++ and optional 'C++ (v141 and v142) Universal Windows Platform tools' were added to VS19 (though this did not fix the problem with debugging). This is all very muddled, with code that compiles correctly in C in one situation not working in another, but changing it to C++ and compiling it with special C++ tools seeming to fix the problem. This took an enormous amount of time. The answers to the 3 questions above should help in the future (though even converting from C to C++ is a pain, and perhaps the wording changes that are needed across the set of C files can be clearly summarized somewhere).

4 replies

I had help from Kaleb at Zemax to sort out the debugging problem. When attaching it, in the 'Attach to' box, it came up with Automatic: Native code, but what was really required was to click on Select, and then choose 'Debug these code types', and check 'Native'. Thereafter, it is forced to always choose 'Native code', but otherwise when OpticStudio is chosen it changes to some other type. Automatic means that it can automatically change it, not that it is automatically set. Double-clicking on OpticStudio was setting it up without attaching, with the appearance that it was using native code. A cross-check on this is to single click on OpticStudio first, and to then look at the Attach to box, to make sure that it actually says Native code. The error when debugging implies that the pdb file is incorrect, which does not really help with working out what the problem is. 

With the other issues, it looks as though the advice is probably to just always use C++ for these dlls. Probably none of the C code that is provided by Zemax works then, so all the files need some sort of modification. Just changing the filename to .cpp seems to tell the compiler to compile it as C++. There are some examples of changes in the help information, but a full list is really needed. One thing with reading in an array was to use these changes:  trans = (double*)malloc(...  ) and      pars = (parse_type*)malloc(...  (Thanks to Kaleb again). There is a        ;#pragma warning ( disable : 4996 )   in some files, but this seems to just ignore some errors. A proper correction seems to be to add the number of bytes to the command, but perhaps just ignoring the errors is always OK (making changes to things like  strcat_s, strcpy_s, etc). And double slashes are need for directory names in c++ (eg '\\ZEMAX\\Miscellaneous'). Looking up the compiler errors online, people have all kinds of software problems, and it isn't always easy to see what the best changes are for this particular code. A list of examples would help. 



A few years back (3-4?), I found that using Pelles C was much easier than using Visual Studio to compile Zemax DLLs. I do not know if that is still the case, but it is way simpler and free. As the sample DLLS are in C, it is more natural.


@Michael Simpson, you saved me! I have spent the whole day trying to understand why VS doesn't load the PDB file! This explicit Native type selection was the thing. I now see that it's sort of mentioned in the myZemax article, but the text is confusing: 'The Attach to box will select the type of code to be debugged... In C++ it will be Native code' It doesn't say that I should select the correct type.

That is great. Glad you found it useful. It would be very useful too if Zemax updated the help information whenever a user finds that something could be clarified. Many calls to the help desk should presumably result in improvements to the documentation, yet nothing seems to change in the written materials. It is great that descriptions are often succinct and clear in the manual, but what you really want is additional information that will help to get your project working. Right then. Having some extra information hidden in a 'knowledge base' does not help either, expecially when it is abnormally slow. Without Zemax having to do any extra work at all, how about just providing a link to a list of things that users have asked about a particular general area of the software, and their solution? A bit like 'other customers also viewed...', but potentially very useful. Even the simplest detail can sometimes be forgotten. 


. . queried. isting adding 


it Once you have something working it is obvious what is going on, and you can read help information from a but can consider updating the