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.

http://www.smorgasbordet.com/pellesc

@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