Hello everyone.
Is there a tool that visually displays DLL dependencies?
Or do I have to do it manually with an UML tool?
Thanks!
https://www.dependencywalker.com/ is the old faithful, and does a good enough job for what I need
1 Like
Hi Paul.
Thanks for your reply…
I know the tool, but it doesn’t work for me because of the circular dependencies.
I wanted to find out exactly where they are.
There are about 30 DLLs in total.
I don’t believe that Depends from DependencyWalker works at all anymore
If you’ve got circular dependencies then I’m not sure the tool really matters.
I assume you have a list of what order you think your DLLs should be compiled in?
If you do then you could just delete all the .LIB files and start compiling the DLLs one after the other. As soon as you hit a DLL that depends on a .LIB that’s compiled later on in the list you’ll get a link error.
But finding the problem is the easy part, the hard part is knowing how to resolve it.
1 Like
I always build the application at least twice in a row, so all the links should be correct.
Yes, the solution is still a bit far away, if even possible.
At the moment, I’m putting everything together using a UML diagram, but that’s very confusing with 30 DLLs.
You might take a look at my App Splitter in GitHub. It does quickly let you see all Imports (from .MAP file) and Exports (from .EXP file). Maybe you could export that info and join it all in a database.
I have exactly what you need but it needs some work to make it easy to use. Paul I think tested it with you 15+ years ago and found some circle calls in JDA’s like 120 projects.
I could probably run your project through it if I had your .MAP and .EXP files.
FYI “Mutual Imports” is another name for Circular DLL References
2 Likes
Yeah, we worked hard to make sure that the base product didn’t have any, but once it got delivered to clients and they started doing their own thing that went out the window 
Things that we would have done a new build for they just ignored because most of them didn’t want the hassle of redeploying the entire product when they could just ship an updated DLL to the enterprise.
Luckily for me that’s not something I have to worry about anymore!
Hi Carl.
That looks amazing!
I don’t understand why I didn’t see this in your collection earlier.
I think I can put the exports/imports into a database and then try to analyze this data.
That certainly won’t be easy, since we’ve divided the apps into categories.
For example, one app handles addresses (A), another handles invoices (B). Now A calls the invoice list in B, but B has the option to display an address from A…I’ll probably only be able to do that if I give up on the “one app, one topic” mentality.
I’m already feeling dizzy…
Where I can find “compileOrder”? I guess that’s from you too, isn’t it?
Regarding the circular DLL references: can this also be the cause of GPFs (AccessViolation)? Even if I compile it multiple times?
Thank you so much for this!
Instead of a data base a quick thought would be in App Splitter it as a Tab of all the Imports that it got by reading the .MAP file:
That list of Apps Imported is all in a Queue. Loop that and for each Imported App load its MAP file to see if it has “Mutual Imports” i.e. what functions do QPr 1,2,6,7,20 … import from this QPr 03. Those are your problems. App Splitter has all the code to load MAP Imports into a Queue, just reuse it to load other Apps.
I have no problem with with Mutual Imports and have a lot of them in projects I currently work on. Everything seems to import everything.
I can see how a GPF could occur during shutdown if DESCTRUCT code was not careful to check if Objects or things it is using have already been destructed. I do work on some code that has a lot of classes that all use each other. They are in Global and Local scope. It was fine in C5 but in C11 it always crashes on shutdown and we have not found the cause.
Its not public. Not sure when I can get to finish it.
One this that can help the build not require 2 iterations is to use #ImpLib to make the LIB’s from the EXP’s before compiling as discussed in this MSBuild Example post.
Does your version of Clarion support bin\ClarionCL.exe?
Ten years ago I was working with a big app that was converted from C6 to C9 and I created a template that was called by ClarionCL and it would create a list of circular calls. I’d have to have a dig around to see if I still have everything.
Let me know if you feel like having a play with it?
I’ve already adapted it and start with the EXE app. After that, each import is further checked until all DLLs have been retrieved.
There are a lot of interdependencies.
Yes, the queue helped me a lot with that. Everything is now in a table that I can easily analyze.
I think that maybe some of the entry points aren’t quite right. If I compile twice, do the addresses stay the same or do they change each time?
I’ve found this approach too: first build all the libraries and then finally build and link the DLL. Can Clarion do that?
I’ll take a look at the MSBuild topic right away, thanks for the link.
I’ve already started redesigning the project a bit, and so far it’s not looking bad.
A rethink is required.
The idea is simply to create “subDLLs” and outsource functions there, but that’s getting confusing. Previously, we’d used prefixes for the module in the function name, so for the DLL “Adr.dll,” all functions start with “ADR:,” so you know right away where each function is located.
Okay, I didn’t know it wasn’t officially available yet…but I’d be interested 
Hi Geoff.
Yes, it does.
Actually we use Clarion 10 bin in Clarion 11 IDE 
Maybe we switch to Clarion 12 completely.
I’m interesset in all hints those can help 
I would like to play with it!
Thank you!
OK, I’ve made a github repository…
Sorry I can’t help you any more with this because I’ve forgotten just about everything about it!
I don’t know if it will be of any help for what you want, please don’t waste too much time on it if it doesn’t seem useful.
Conversely, I’d be delighted to hear if it was useful! 
1 Like
To make it easier to pursue Circular Refs I enhanced App Splitter to add an “Open DLL” button on the Imports tab. Tis makes it easy to It pops up a list of Imported DLLs that have a Clarion Map.
Below you see the popup shows UTBLG imports UT00, UTMnt and UTRec.
Clicking on UTMNT in the popup opens that in App Splitter then displays the Imports tab with UTMNT selected and expanded. It shows that UTMNT imports 10 procedures from UTBLG. Using the two instances you can see all the Mutual Imports (Circular Refs) between UTBLG and UTMNT DLLs.
2 Likes
Thanks for the extension, that makes all quicker!
I’m still planning.
This whole thing isn’t as easy as I thought.
I just can’t resolve some references without rewriting the entire function.
It’s still a mess.
I have to resolve it all piece by piece.
At least the addresses for the linker remain stable when compiling multiple times in a row.